What is Scrum? A complete guide to the framework and its ceremonies

Scrum is the most widely used framework for organising software delivery, and also one of the most widely misunderstood. Plenty of teams "do Scrum" in the sense that they have standups and sprints, yet still miss the point of the framework entirely: a short, repeating loop that turns guesswork into evidence.

This guide covers the whole framework from first principles. It explains where Scrum came from, what it is actually for, who does what, and how the five events fit together. It is the first in a series; each ceremony gets its own detailed guide, linked as we go.

Where Scrum came from

The name comes from rugby. In 1986, Hirotaka Takeuchi and Ikujiro Nonaka published an article in Harvard Business Review called "The New New Product Development Game". They studied product development at companies like Honda and Canon and noticed that the best teams did not pass work down a line, phase by phase, the way a relay race passes a baton. Instead, a single cross-functional team moved down the field together, like a rugby scrum, overlapping the phases and adjusting constantly.

Jeff Sutherland and Ken Schwaber turned that idea into a concrete software process in the early 1990s and presented it formally at the OOPSLA conference in 1995. Since 2010 the framework has been defined in a short document called the Scrum Guide, which the two of them still maintain. The most recent revision, from November 2020, made the framework simpler and less prescriptive, and it is the version this series is based on.

One story worth knowing, because it shows what Scrum is for: the FBI spent years and hundreds of millions of dollars on a case management system called Sentinel, using a traditional plan-everything-up-front approach, and got almost nothing usable. The project was rebooted with a small team working in short cycles, delivering working software every few weeks and adjusting the plan based on what they learned. It shipped. Sutherland tells the story in detail in his book, and it captures the core bet of Scrum: you learn more from delivering a small real thing than from planning a large imaginary one.

Empiricism: the idea underneath everything

Scrum is built on empirical process control, which is a formal way of saying: in complex work, you cannot plan your way to certainty, so you should run the work as a series of experiments and steer with the results.

Three pillars hold that up:

• Transparency. The work and its state must be visible to the people doing it and the people depending on it. If the real state of the sprint lives in someone's head, or in a spreadsheet that was accurate last Tuesday, you cannot inspect anything. This is the practical reason teams run their work on a shared, live board rather than in status emails. In WannaTrack the board, the backlog, and the reports are all views of the same data updating in real time, which is one way of making transparency the default rather than a chore.
• Inspection. You look at the work and the process frequently, at defined points, so problems surface while they are still small. Every Scrum event exists to inspect something specific.
• Adaptation. When inspection shows you are off course, you adjust. A plan that cannot change in response to evidence is not a plan, it is a wish.

If you remember one thing from this guide, make it this: every rule in Scrum exists to serve those three pillars. When you are unsure whether some practice is "proper Scrum", ask whether it increases transparency, enables inspection, or supports adaptation. That question settles most arguments.

The five values

The 2020 Scrum Guide names five values: commitment, focus, openness, respect, and courage. It is easy to skim past them as poster material, but they predict team success better than any mechanical practice does.

A concrete example. A team at a fintech we spoke with had flawless ceremonies: planning on Monday, standup at 9:15, review and retro every second Friday. But in the retro nobody ever raised the thing everyone complained about at lunch, which was that one senior engineer rewrote everyone else's code without asking. No openness, no courage, so no adaptation, so the retro was theatre. The ceremonies were fine. The values were missing, and the framework quietly died. Mechanics are the easy part; the values are the actual work.

The Scrum team

Scrum defines exactly one team structure: a Product Owner, a Scrum Master, and Developers. No sub-teams, no hierarchy inside the team. The 2020 guide deliberately dropped the term "Development Team" because it created a team within a team; there is just one Scrum team, self-managing, typically ten people or fewer, with everything it needs to turn an idea into a usable increment.

The Product Owner owns the "what" and the "why". They order the product backlog so it maximises value, and they are one person, not a committee. A good Product Owner says no constantly, in public, with reasons. A common failure mode is the "backlog administrator" who accepts every request and files it, producing a backlog of nine hundred items where nobody can tell what matters. Order is the Product Owner's real product: the backlog in WannaTrack is a single drag-ordered list for precisely this reason, because a priority field with four values lets you avoid deciding, and a strict order does not.

The Scrum Master owns the process. They coach the team on Scrum, remove impediments, and shield the team from anti-patterns like mid-sprint scope injection. The title misleads people; the role has no authority over the team and is closer to a coach than a manager. A useful test: if the Scrum Master goes on holiday and the standup collapses, they have been running the team rather than growing it.

The Developers are everyone who builds the increment: engineers, designers, testers, writers, whoever the work needs. They own the "how", they size the work, and they decide how much of it fits in a sprint. Nobody assigns work into a sprint from outside the team, and that includes the Product Owner.

The artifacts and their commitments

Scrum has three artifacts, and the 2020 guide paired each with a commitment that gives it focus:

• The Product Backlog, committed to the Product Goal. The backlog is the single ordered list of everything the product might need. The Product Goal is the longer-term objective the backlog currently serves, so the list has a direction rather than being a junk drawer.
• The Sprint Backlog, committed to the Sprint Goal. The sprint backlog is the set of items the team pulled into the sprint plus their plan for delivering them. The Sprint Goal is the one-sentence reason the sprint exists. It is the difference between "we did nine of the eleven tickets" and "customers can now pay by invoice". More on this in the sprint planning guide.
• The Increment, committed to the Definition of Done. The increment is the sum of usable, finished work. The Definition of Done is the team's shared, written standard for "finished": for example, code reviewed, tests passing, deployed behind a flag, documented. Without it, "done" means something different to every person, and the sprint's apparent progress is fiction. Teams often keep their Definition of Done where the work lives; a pinned doc next to the board works well, and WannaTrack's docs sit inside the project for exactly this kind of working agreement.

The five events

People say "the four ceremonies", but Scrum defines five events, and the first one is the container for the rest.

The Sprint is a fixed timebox of one month or less, most commonly two weeks, in which the team produces a usable increment. Sprints run back to back with no gaps and no "hardening sprints". The fixed length is the point: it turns delivery into a steady rhythm you can measure, rather than a series of one-off pushes. Once a team has a few sprints of history, its velocity (the amount of work finished per sprint) becomes a planning instrument, which is why WannaTrack shows recent velocity right next to the backlog while you plan.

Sprint Planning starts the sprint. The team answers three questions: why is this sprint valuable, what can we get done, and how will we do it. Output: a Sprint Goal and a sprint backlog the Developers chose themselves. Timebox: at most eight hours for a one-month sprint, so roughly half a day for two weeks. Read the full sprint planning guide.

The Daily Scrum is fifteen minutes, every working day, for the Developers to inspect progress toward the Sprint Goal and adjust the day's plan. It is not a status report to a manager. The 2020 guide even removed the famous three questions to stop it degenerating into one. Read the full daily scrum guide.

The Sprint Review ends the sprint's work. The team and its stakeholders inspect the increment together and decide what to do next, which frequently changes the backlog. It is a working session, not a demo performance. Read the full sprint review guide.

The Sprint Retrospective closes the sprint. The team inspects itself, people, process, tools, and picks a small number of concrete improvements for the next sprint. It is the event that makes all the other events better over time, which arguably makes it the most important of the five. Read the full sprint retrospective guide.

There is also backlog refinement, which is not an event but an ongoing activity: adding detail and size to backlog items so that planning has something ready to plan with. Most teams run it as a recurring session anyway, and it deserves its own craft, so it gets its own refinement guide.

For a two-week sprint, the whole ceremonial overhead comes to roughly four to six hours plus ten standups: something like five percent of the team's time. When people complain that Scrum is "all meetings", the meetings are usually being run badly, or other meetings have crept in around them.

What Scrum is not

A few boundaries that save a lot of confusion:

• Scrum is not a full methodology. It says nothing about how to write code, test, deploy, or design. Teams pair it with engineering practices (continuous integration, code review, automated testing) and often with Kanban-style flow inside the sprint. The framework is deliberately incomplete.
• Scrum is not about story points or velocity. Neither term appears in the Scrum Guide. They are popular companion practices, useful for forecasting, covered in our refinement guide, but they are optional instruments, not the goal.
• Scrum does not scale by adding process. When multiple teams share a product, the usual first step is a short cross-team sync often called a Scrum of Scrums, where each team surfaces progress and cross-team blockers. Tooling can shrink this meeting dramatically: WannaTrack's portfolio view rolls every project's sprint health, risk, and blockers into one screen, so the meeting spends its time on the two red items instead of reciting the eight green ones.

Common ways Scrum fails, and what they look like

You can diagnose most struggling Scrum adoptions from a distance, because the failure modes repeat:

• Waterfall in two-week costumes. The "sprint" is just a slice of a fixed eighteen-month plan, nothing ships until the end, and the review inspects slideware. The loop exists but nothing flows through it.
• The invisible sprint. Work is tracked in five places or none, so the standup is the only moment anyone knows the true state, and it stretches to forty minutes. The fix is boring and effective: one live board that is always the truth.
• Velocity as a performance target. The moment management grades teams on velocity, estimates inflate and the number stops meaning anything. Velocity is a forecasting input, never a KPI.
• The skipped retro. Under pressure, teams cut the retrospective first, which is exactly backwards: it is the mechanism for relieving the pressure. A team that has stopped inspecting itself is no longer doing Scrum, whatever its calendar says.

Getting started

If you are adopting Scrum fresh, resist the urge to customise on day one. Run it plainly for three or four sprints first:

1. Form one cross-functional team of ten or fewer, with a named Product Owner and Scrum Master.
2. Write a Product Goal and build a single ordered backlog toward it. If your work currently lives in Jira, you can bring it across in one pass rather than starting from a blank page.
3. Agree a Definition of Done and write it down where the team works.
4. Pick two-week sprints, put all five events in the calendar, and hold the first sprint planning.
5. After three sprints, use your first real velocity numbers and your retro notes to start adapting the process to your team.

The rest of this series goes deep on each ceremony: what it is for, exactly how to run it, and the anti-patterns to watch for. Start with sprint planning, because everything else in the sprint inherits its quality from that first meeting.