Scrum

Scrum on one screen

Here is the whole framework first, because it is small enough to fit on one screen and most descriptions scatter it across ten. The official Scrum Guide defines three accountabilities, three artefacts — each with a commitment attached — and five events, and the entire document runs to about thirteen pages. The first table lists the five events, plus refinement, which the Guide calls an ongoing activity rather than an event, and the three meetings most real teams add on top.

The timeboxes are the Guide’s maximums for a one-month sprint. The two-week figures after the slash are the usual proportional practice, not a rule: the Guide says only that for shorter sprints the events are usually shorter.

And the rest of the framework: three accountabilities, and three artefacts, each with the commitment that turns a list into something you can measure.

What it rests on: empiricism

Let us start with the confusion that trips up almost everyone new to this. People say "we work by Scrum" and mean that they have daily meetings and a board with columns. Those are the visible parts. What Scrum actually is sits underneath them: a way of working empirically — deciding from what you observe rather than from what you predicted.

The Guide names three pillars for that, and they depend on each other in order. Transparency makes inspection possible; inspection makes adaptation possible. In the Guide’s own words, inspection without transparency is misleading and wasteful, and inspection without adaptation is pointless.

Each event is a formal opportunity to inspect one thing and adapt another. The diagram shows the artefacts as a pipeline — Product Backlog to Sprint Backlog to Increment — with the events sitting on it as inspection points, and each artefact carrying its commitment underneath.

The five values

The Guide also names five values, and says that Scrum succeeds when people become more proficient in living them. They are easy to recite and hard to observe, so here is what each one looks like during a sprint — and what its absence looks like, which is usually easier to spot.

Every event, one by one — and the four teams add

Here is where most descriptions of Scrum stop short. The official guide defines five events. Real teams run more than that, and the extra ones matter — a team that skips them tends to arrive at planning with work nobody understands.

We will go through all of them in the order they occur. For each one: what it is, who is there, how long it takes, and what goes wrong when it is done badly.

The Sprint — the container for the other four

The first event is easy to miss because it is the one everything else happens inside. A sprint is a fixed period of time — one month or less, and most teams choose two weeks — during which the team works towards one agreed goal and produces something genuinely usable at the end. A new sprint starts the moment the previous one ends.

Two words in that sentence do a lot of work. "Fixed" means the sprint does not get extended because the work is not finished — if something is not done, it goes back to the backlog and the sprint still ends on schedule. "Usable" means the result could genuinely be given to a user, not that it compiles or that a branch exists.

Why fix the length at all? Because a fixed rhythm turns planning into a habit rather than a decision. Everyone knows when the next planning session is, when the next review is, and how much time is left. It also makes the team’s capacity measurable: after four sprints of the same length, you have real data about how much this team finishes in two weeks.

One rule most teams never need and should still know: only the Product Owner can cancel a sprint, and only when its goal has become obsolete — the market moved, the feature was dropped. The diagram below shows the full path a team walks through a sprint, in the order it actually happens.

Kick-off — once, at the very start

A kick-off is the meeting that starts a project or a major new phase. It is not part of the official Scrum framework at all, but almost every real team holds one, and skipping it causes months of quiet confusion.

The purpose is to get everyone to the same starting point. The team hears why this product exists, who the users are, what business result is expected, and what the constraints are — the deadline, the budget, the technology that is already chosen. StakeholdersStakeholderanyone the outcome affectsAnyone whose work or results are affected by what is being built, whether or not they can decide anything about it. The distinction that matters in practice is between those who are consulted and those who can say no.All terms meet the people who will build it. Everyone agrees how they will communicate.

A kick-off usually runs from two hours to a full day, depending on how much is new. Everyone attends: the whole team, the Product Owner, the Scrum Master, and the key stakeholders. This is the one meeting where having too many people in the room is better than having too few.

Sprint Planning — opens every sprint

Planning is the meeting where the team decides what it will do in the coming sprint. It is one of the five official events, and it answers three questions in order.

• Why is this sprint worth running? The team agrees a Sprint Goal — one sentence describing what will be different at the end.
• What can we deliver? The team picks items from the backlog that serve that goal, and only as many as it can realistically finish.
• How will we do it? The developers break the chosen items into concrete steps — this part belongs to the team, not to the Product Owner.

Planning is timeboxed to a maximum of eight hours for a one-month sprint, and usually about four for a two-week one. In practice a well-prepared team finishes in ninety minutes, and that is a good sign rather than a wasted timebox. The reason it can be that short is refinement, which we will come to shortly.

What the team selects is a forecast, not a promise. The Guide changed that word from "commit" to "forecast" in 2011 for a reason: a number of items treated as a promise gets met, and it gets met by quietly lowering the quality of each one.

Daily Scrum — fifteen minutes, every day

The Daily Scrum is a short meeting held at the same time and place every working day. Fifteen minutes, standing up in many teams, and only the developers are required to be there.

Its purpose is often misunderstood, so let us be precise. The Daily Scrum is not a status report to a manager. It is the team re-planning the next twenty-four hours between themselves, based on what they learned yesterday. The question it answers is: given where we are now, what is the fastest path to the Sprint Goal today?

You may know the three questions — what did I do yesterday, what will I do today, is anything in my way. They were only ever an example. The 2017 Guide made them optional and the 2020 Guide removed them altogether, because read out one person at a time they turned the event into exactly the status report it was meant to replace.

Brainstorm — when the team hits something unknown

Sometimes an upcoming piece of work is genuinely unclear. Nobody knows which approach to take, or whether the thing is even possible with the current architecture. Estimating it would be guessing, and decomposing it would be inventing steps for a solution nobody has chosen yet.

That is what a brainstorm is for. The team gathers — usually for one to two hours — specifically to explore the problem before any estimation happens. People sketch approaches, argue about trade-offs, and often agree to run a spike: a short timeboxed experiment, typically one or two days, whose only output is knowledge rather than shippable code.

A brainstorm is not in the official Scrum Guide, and it does not need to be — nothing in Scrum forbids a team from meeting when it needs to. It happens as needed rather than on a schedule, which is why the diagram shows it as an optional branch rather than a fixed point.

Presentation — introducing new work to the team

Before a team can estimate anything, it has to understand what is being asked. The presentation is the meeting where the Product Owner walks the team through new items that have appeared in the backlog. Like the kick-off and the brainstorm, it is common practice rather than part of the Guide.

It starts one-way: the Product Owner explains the business need, who asked for it, what problem it solves, and what success would look like. Then it turns into a conversation. Developers ask the questions that reveal hidden complexity — "does this apply to existing users too?", "what happens if the payment fails halfway?" — and those questions frequently change the requirement before a single line is written.

After the discussion, the team decomposes the item together: breaking one large request into smaller pieces that can each be built and checked on their own. Nothing is estimated yet. The goal of this meeting is shared understanding, and estimating before understanding is where most bad numbers come from.

Backlog Refinement (grooming) — where estimation happens

Refinement — many teams still call it grooming, which was the older name — is the working session where the backlog is made ready. The Guide treats it as an ongoing activity rather than an event, which is why it has no timebox of its own. In practice most teams hold it as a session anyway: the Product Owner and the developers, often with the Scrum Master, take the items that were presented and decomposed earlier and do three things to them.

• Clarify — anything still ambiguous gets pinned down, and acceptance criteriaacceptance criteriahow this story will be judged doneThe conditions one piece of work must meet to be accepted, agreed before it is built — for example, that an expired promo code is rejected with its expiry date. They differ from a Definition of Done, which applies to every piece of work; fifteen of them on one story usually means it is several stories.Full article →All terms are written: the concrete checks that decide whether the item is done.
• Split — anything too big to finish inside one sprint is broken down further.
• Estimate — the team assigns a size to each item, so the Product Owner can order the backlog knowing the cost of each option.

Estimation is where planning pokerplanning pokersizing by simultaneous revealA way for a team to size backlog items: everyone picks a card from a fixed scale privately, and all the cards are turned over at once, so nobody anchors on the first voice. Its value is the discussion when the cards disagree — a 2 and a 13 on the same item mean two people understand the task differently.Full article →All terms usually appears. Everyone privately picks a number from a limited set — commonly 1, 2, 3, 5, 8, 13, following the Fibonacci sequence — and all reveal at once. The numbers are relative sizes rather than hours: an 8 is roughly twice the work of a 5, not eight hours of typing.

The value of revealing simultaneously is not the number. It is the disagreement. When one person says 2 and another says 13, they are not arguing about arithmetic — they understand the task differently, and the conversation that follows is the whole point of the exercise. The number the team lands on matters far less than the misunderstanding it uncovered.

Planning poker is not mandatory. Some teams use t-shirt sizesT-shirt sizingsizes XS–XL instead of numbersA coarse way of estimating that sorts items into classes — XS, S, M, L, XL — instead of giving them numbers, used for roadmaps, epics and first conversations about cost. It works only if each size is agreed to mean a range of real time; added up as if the sizes were numbers, it produces a precise-looking total that means nothing.Full article →All terms (S, M, L), some count items without sizing them at all and rely on measured throughput instead. All of these work. What does not work is skipping the conversation.

A practical guideline: spend up to about ten percent of the team’s capacity on refinement. Earlier editions of the Guide gave that number; the 2020 edition dropped it but kept the activity. For a two-week sprint it is roughly one session of two to four hours, or two shorter ones. And remember what the diagram showed — the items you refine now are for the next sprint, not this one.

Sprint Review — showing the result

Near the end of the sprint the team shows what it built. Key stakeholders are invited, the increment is demonstrated on a working system rather than in slides, and everyone discusses what should happen next.

The review is a working session, not a ceremony of approval. Its real output is an updated backlog: stakeholders see the thing, react to it, and their reaction changes what the team does next. A review where nobody says anything surprising has not done its job.

Timebox: up to four hours for a one-month sprint, so around two hours for a two-week one. Only finished work is shown — items that are nearly done are not demonstrated, because "nearly done" is how a team quietly loses the meaning of done.

Retrospective — closing the sprint

The retrospective is the last event of the sprint, and it is about the team rather than the product. The review asked "is what we built right?"; the retrospective asks "is the way we work right?" — including whether the Definition of Done should be tightened.

The team looks back at the sprint and discusses what helped, what got in the way, and what to change. Only the team attends — adding managers changes what people are willing to say, and a retrospective where nobody says the difficult thing is worth nothing.

Timebox: up to three hours for a one-month sprint, about ninety minutes for two weeks.

Three accountabilities, and why the limit is ten

Scrum defines three areas of responsibility. The official name is "accountabilities" rather than roles, and the distinction is small but real: these are things someone is answerable for, not job titles printed on a contract.

• Product Owner — what

  Decides what gets built and in what order. One person, never a committee, because a backlog ordered by a group is a backlog ordered by whoever argued hardest.

• Scrum Master — how well

  A leader who serves the team: removes obstacles, protects the sprint from interruption, coaches the team and the organisation. Does not assign tasks and does not report status upward.

• Developers — how

  Everyone who builds the increment, whatever their speciality — backend, QA, design. They decide the technical approach and are jointly responsible for the result.

Notice who is missing. There is no project manager in a Scrum team, no tech lead who assigns work, and no separate QA gate at the end. Those functions may well exist elsewhere in the company, but Scrum does not give them authority over how the team works. That is often the hardest part of adopting it honestly.

Then the size. The Guide says a Scrum Team is typically ten or fewer people — and that ten includes the Product Owner and the Scrum Master. The reason is arithmetic rather than taste.

Every pair of people is a channel along which a misunderstanding can travel, and the number of pairs grows much faster than the headcount. Going from ten people to fifteen adds half again to the team and more than doubles the conversations. The first place it shows is the Daily Scrum: at fifteen it can no longer be a conversation about the goal, and turns into a round of individual reports.

When a team grows past that, the Guide’s answer is not one bigger team. It is several cohesive Scrum Teams sharing one Product Goal, one Product Backlog and one Product Owner — which is precisely what Nexus, LeSS and Scrum@Scale each formalise in their own way.

The Definition of Done, and where it stops

Each artefact carries a commitment, and of the three the Definition of Done is the one teams most often leave vague. It is a written checklist that applies to every item: code reviewed, tests written and passing, deployed, documentation updated — whatever the product genuinely requires before a user can have it. If it is not written down, "done" means something slightly different to each person, and that difference surfaces at the worst possible moment.

The Guide is strict about it. The moment an item meets the Definition of Done, an increment is born. An item that does not meet it cannot be released and should not even be shown at the review; it goes back to the Product Backlog. Where the organisation has a Definition of Done, every team uses it as a minimum; where it has none, the team must write its own.

What matters most is where it stops. The diagram shows the same six sprints under two definitions — one that ends at "merged", one that ends at "releasable".

Scrum or Kanban?

This is the question most teams face at some point, so let us make it decidable rather than philosophical. The two differ in one structural way: Scrum batches work into a fixed cycle and commits to a goal, while Kanban lets work flow continuously and commits to a limit on how much is in progress at once.

And if you find yourself wanting both — the rhythm of Scrum with the flexibility of Kanban — that combination has a name and a page of its own: Scrumban.

Five documented episodes, and the rule each one tested

Scrum has been around for three decades, which is long enough to have a documented record of what happens when each rule is kept and when it is quietly dropped. The first entry is the rescue story Scrum’s own marketing tells most often, told with the parts the marketing leaves out.

Where it degrades

The honest limit: Scrum makes problems visible within a sprint, and it solves none of them. A team with no engineering practice, a Product Owner without authority, or an organisation that cannot release will see those problems every two weeks, clearly, for as long as it runs Scrum — and nothing in the framework will fix them. That is by design, and it is why "Scrum did not work for us" so often means "Scrum showed us something we did not act on".

• A Definition of Done that stops short of releasable, so "done" work still needs a stabilisation sprint later.
• No refinement, so every planning session turns into a four-hour attempt to understand the work.
• A Product Owner without real authority, so the backlog order is set by whoever escalated loudest.
• Sprints used only as a reporting rhythm while releases stay quarterly — the vocabulary without the loop.
• Velocity treated as a productivity target, which reliably inflates estimates rather than output.
• The Daily Scrum run as a round of reports to the Scrum Master, the three retired questions read out one person at a time.
• A sprint extended "just this once" because the work is not finished.
• A Scrum Master working as a project manager — assigning tasks and reporting status upward.
• A team of fifteen running one Daily Scrum.
• Retrospectives that produce discussion and never an action with a name on it.

When to use it

Related pages

• ManagementAgileAgile is a set of four values and twelve principles for building software, written in 2001, that puts learning from working software ahead of the plan. It is not a methodology — Scrum, Kanban and Extreme Programming are the methodologies built on top of it — and it has no meetings, roles or artefacts of its own. The page opens with the Manifesto in full, numbered so a line can be cited, then covers the layer it occupies, what each value trades, the bet it makes on the cost of change, feedback loops as its real mechanism, each principle as a test you can run on your own team, six programmes it decided, and where it degrades into theatre.
• ManagementKanbanKanban is a way of managing work that starts from your current process and improves it by limiting work in progress and measuring how that work flows. It adds no roles and no sprints. The page opens with every element of a Kanban system on one screen — what a team writes down and what its absence looks like — then covers why a board alone is not Kanban and the two bodies that define the method, its six principles and six practices, the four flow measures and the arithmetic under them, forecasting from history instead of estimates, the seven cadences, five documented cases, and where it degrades.
• ManagementScrumbanScrumban is a way of running a team that keeps Scrum’s regular meetings but swaps the sprint commitment for Kanban’s WIP limits and planning on demand. Corey Ladas coined the name in 2008 for a path from Scrum toward continuous delivery; most teams now use it for a stable hybrid. The page opens with every Scrum element and what becomes of it, then covers why the hybrid exists, the two meanings of the word, the three numbers that define it, how planned work and interrupts share one board, planning beyond the next fortnight, a side-by-side with its parents and one measured switch, and where it degrades.