Agile and Scrum: Where They Came From and How Teams Use Them

Scrum and agile get tangled because one grew out of the other. Agile is a set of values about shipping work in small pieces and adjusting as you learn. Scrum is the framework most teams use to put those values to work, with named roles, fixed-length sprints, and a short list of meetings. Somewhere along the way the names became interchangeable in conversation, and teams started saying scrum when they meant agile, or agile project management when they meant the board in the corner.

This is the plain-English version of both: where they came from, who invented them and why, what the five agile ceremonies are for, and how teams actually run them today.

What agile actually is

Agile is a set of values, not a process. The Manifesto for Agile Software Development, written in February 2001, states four of them: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. Twelve principles explain how the values look in practice, things like delivering working software every couple of weeks and letting the people doing the work decide how it gets done.

Notice what is missing. Agile names no meetings, no roles, no board columns. Ask someone to explain agile methodology and they usually reach for a framework instead, because the values alone do not tell you what to do on Monday morning. That gap is why frameworks exist. An agile methodology in the everyday sense is whichever framework a team picked to live the values: scrum, kanban, XP, or one of the others. Agile practices are just the routines a team keeps to make those values real, whether that is a ranked backlog or a demo every second Friday.

When people say agile approach or agile process, they mean the same broad idea. The word itself describes an operating stance: build a small piece, show it to real users, adjust.

What scrum actually is

Scrum is the framework most teams pick, and the one people usually mean by scrum methodology. The scrum framework takes the agile values and gives them a schedule and a cast: sprints of one to four weeks, three roles (Product Owner, Scrum Master, and Developers), four events inside each sprint, and three artifacts. The current Scrum Guide is short enough to read in an afternoon and free at scrumguides.org, which is one reason it spread so far: any team can adopt the whole thing over coffee.

In scrum project management terms, the sprint is the drumbeat. A scrum sprint pulls work from a ranked product backlog into a sprint backlog, the team builds until the sprint ends, then demos what shipped and decides what to change. If you want the hands-on version with a worked first sprint, that lives in Scrum for Small Teams. This article stays at the level of where it all came from and why it took over.

Where agile and scrum came from

The problem they were built for

Through the 1970s and 1980s, most software ran on a waterfall plan: gather every requirement, design everything, build it all, test, then deliver. Winston Royce described the model in a 1970 paper, though his own point was that the one-way flow fails without feedback loops running backward. The industry heard the diagram and skipped the caveat.

The 1990s put numbers on the failure. The Standish Group's first CHAOS report, published in 1994, found 16 percent of software projects finished on time and on budget, 31 percent were cancelled outright, and the rest ran late or shipped short of the promise. Teams facing those numbers wanted a way to surface problems in weeks instead of at delivery.

1986: the rugby paper

The word scrum entered product development before scrum existed. In 1986, Hirotaka Takeuchi and Ikujiro Nonaka published The New New Product Development Game in the Harvard Business Review, a study of manufacturers including Honda, Canon, and Fuji-Xerox that shipped products faster by running phases in overlap instead of sequence. They compared the winning teams to a rugby team that moves down the field as a unit, passing the ball back and forth, and called the shared hand-off point a scrum.

The paper was about hardware and consumer products, not software. Software people read it anyway and kept the metaphor.

1993 to 1995: scrum gets built

Jeff Sutherland, an engineer and former air force pilot, read the 1986 paper and applied it to software at Easel Corporation in 1993. His first version of the scrum process paired overlapping work with sprints, short fixed timeboxes at the end of which something demonstrable existed. Ken Schwaber had been running a similar process at DuPont, and the two merged their work. They presented the SCRUM Development Process paper at the OOPSLA conference in Austin, Texas, in 1995.

The name came straight from the rugby metaphor. A scrum in rugby is how the ball goes back into play after a stoppage: forwards lock together and contest it as one unit. Sutherland and Schwaber took the name to mean the whole team working the problem together rather than a relay of hand-offs.

February 2001: seventeen people at a ski resort

By the late 1990s several lightweight methods were circulating, including scrum, XP from Kent Beck, Crystal from Alistair Cockburn, DSDM, and Feature-Driven Development. In February 2001, seventeen of the people behind them met at the Snowbird ski resort in Utah for two days. They came out with a one-page document, the Manifesto for Agile Software Development, and picked the word agile over the label lightweight methods, which the industry kept using as a polite way to say less rigorous.

The group called itself the Agile Alliance. The manifesto is the famous page, but the twelve principles underneath it are the part that actually changes how a team works.

2010 and 2020: scrum gets its rulebook

Scrum ran for years on conference talks and training material. Schwaber and Sutherland published the first Scrum Guide in 2010 and revised it in 2020, trimming the scrum framework to its essentials: three roles, five events including the sprint itself, and three artifacts each with a commitment. The 2020 edition renamed the Development Team to Developers, added the Product Goal, and caps a scrum team at ten or fewer people including the Product Owner and Scrum Master.

Jira launched in 2002 as a bug tracker, and over the following decade agile boards and sprint reports turned enterprise software into the place where scrum actually lives. The word ceremonies is not in the Scrum Guide, which calls them events. Teams called them meetings, and agile ceremonies stuck as the everyday name for the whole set.

Why scrum and agile were invented

Every piece of this history answers the same complaint: big plans fail late. The manifesto's authors wanted short feedback loops so wrong ideas die cheap. The scrum methodology supplies the schedule that makes the loops regular, and the values respond to change instead of defending a plan written months earlier. That is the whole invention. Everything else, the boards, the burndowns, the standups, is scaffolding teams added to keep the loops honest.

The five agile ceremonies

The Scrum Guide names five events, and the sprint is the container that holds the other four. Teams add one more, backlog refinement, until the set feels complete. These are the meetings people mean by agile ceremonies:

Ceremony	Timebox for a two-week sprint	What it decides
Sprint planning	About 4 hours	One sprint goal and the sprint backlog
Daily scrum (the standup)	15 minutes, daily	What moved, what's stuck, today's focus
Sprint review	Up to 2 hours	What gets demoed and accepted
Sprint retrospective	Up to 90 minutes	One process change for the next sprint
Backlog refinement (informal)	Ongoing, up to 10% of capacity	What the next sprints can pull

Timeboxes scale with sprint length. The Scrum Guide states maximums for a one-month sprint: eight hours of planning, four hours of review, three hours of retrospective. Teams running two-week sprints usually halve them. The daily scrum stays fifteen minutes at every length.

Two habits decide whether the ceremonies work. Keep the daily scrum to the three questions and park anything longer for after, and end every retrospective with one concrete change, because a retro that lists ten problems and fixes none is just a complaint session.

How teams use scrum and agile today

Most software teams run some form of agile now, which is why agile development shows up in half the job ads you scroll past. The framework choices concentrate on scrum and kanban, with hybrid boards everywhere in between:

Sprint teams (scrum). The full framework above: ranked backlog, fixed sprints, four events, three artifacts. Product and engineering teams that plan in releases.
Flow teams (kanban). No sprints, work-in-progress limits, cards moving whenever they are ready. Toyota used the card system on factory floors in the 1950s, and David Anderson's 2010 book turned it into the kanban method for knowledge work. Scrum vs Kanban covers the trade-offs.
Hybrids (agile kanban). A board with a sprint cadence on top, common in support and operations where work arrives faster than a sprint can absorb it.
Beyond software. Marketing and operations teams run campaigns and monthly closes in sprints now, which is what agile project management means outside engineering: the same cadence applied to non-code work.

Sprint management in practice is four recurring jobs: keep the backlog ranked, hold the sprint scope still once planned, demo on the last day, and close with one retro change. None of this needs a specific tool for a team of five. A whiteboard and sticky notes work until the backlog outgrows the wall or part of the team goes remote, which is the point where teams start comparing agile project management tools.

What to expect from agile project management software

Most agile project management software claims scrum support. Four checks matter before anything else:

A ranked backlog with drag reordering. The top of the list is what's next.
Sprints on a length you choose, with automatic rollover of whatever didn't finish.
A burndown or throughput report that shows the plan against what happened.
Pricing that doesn't tax the ceremonies. The meetings are free, so the tool should be a small line item. A $30 seat and a $10 seat differ by $2,400 a year at ten people, which buys a lot of retro snacks.

Taskora

Full disclosure, we build it. Taskora runs scrum mechanics without the enterprise weight. Sprints here are called waves: planning cycles you name, with a length from one week to one month, and each stream, a project in your workspace, defines its own cycle so marketing and engineering can run different cadences side by side. A wave moves through plan, active, and completed, and once completed it takes no new tasks. Anything unfinished rolls into the backlog automatically.

Each stream carries its own kanban board with custom statuses, docs with version history for retro notes, and wave and stream reports including burndowns. The sprints page shows the full flow. Pricing is flat: one plan, every feature, $13 per seat per month billed monthly or $10 per seat per month billed yearly. The teams page shows what a ten-person team pays and gets.

Taskora is cloud-hosted with data encrypted at rest and in transit. Self-hosting on your own servers is available on request.

Agile and scrum: frequently asked questions

What is the difference between agile and scrum?

Agile is the philosophy, four values and twelve principles about shipping work in small pieces and adjusting as you learn. Scrum is the most common framework that implements it, with roles, sprints, and events. Every scrum team is agile, and plenty of agile teams are not doing scrum.

Who invented scrum and agile?

Scrum: Jeff Sutherland and Ken Schwaber, who built the process at software companies in the early 1990s and presented it at the OOPSLA conference in 1995. The name borrows from a 1986 Harvard Business Review paper by Takeuchi and Nonaka. Agile: the seventeen co-authors of the 2001 Manifesto for Agile Software Development, written at a two-day meeting at the Snowbird ski resort in Utah.

What are the five agile ceremonies?

Sprint planning, the daily scrum, sprint review, and the sprint retrospective, held inside the sprint. Backlog refinement is the informal fifth, and the sprint itself counts as the container event in the current Scrum Guide.

How long is a sprint?

One to four weeks, with two weeks the most common choice. The Scrum Guide caps a sprint at one month. Keep one length for at least three sprints before judging it.

Is kanban agile?

Yes. Kanban is the other major agile framework: continuous flow with work-in-progress limits instead of fixed sprints. Toyota used the card system in the 1950s, and David Anderson adapted it for knowledge work in his 2010 book. Scrum vs Kanban walks through when each fits.

What is agile project management?

Running projects in short increments with feedback after each one, instead of one long plan executed to the end. In practice that means a ranked backlog, a board, a regular cadence of demos, and a team that changes the plan based on what the demos show.

Try Taskora with your next sprint

Bring one real project over, because sample boards flatter every tool. Set up one stream, plan a two-week wave with ten real tasks, and hold the four ceremonies on your usual schedule. Right now, it's free to start until November 1, no credit card needed. After that, there's a 14-day free trial. We don't offer a permanent free tier today.

Try Taskora