Scrum

What Scrum actually gives you

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. That is not really what Scrum is, and mistaking the meetings for the method is why so many teams get the ceremonies and none of the benefit.

Scrum is a framework — a small set of rules about how a team organises itself, and nothing more. It defines exactly three things: three areas of responsibility, three artefacts, and five events. That is the entire official specification, and it fits in a document of about thirteen pages.

Notice what is not in that list. Scrum says nothing about how to estimate work, how to structure your git branches, how much testing is enough, or what your architecture should look like. That is deliberate. The framework assumes your team is competent enough to decide those things itself, and it would be wrong to prescribe them for every team on the planet.

The sprint: the heartbeat

Everything in Scrum happens inside a sprint. A sprint is a fixed period of time — most teams choose two weeks — during which the team works towards one agreed goal and produces something genuinely usable at the end.

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.

Now let us look at the ceremonies that fill a sprint. The diagram below shows the full path a team walks, in the order it actually happens.

Every ceremony, one by one

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.

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. Stakeholders 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, which scales down proportionally — so about four hours for a two-week sprint. 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.

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?

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.

This is a one-way meeting in one direction only at the start: 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 Product Owner, the Scrum Master and the developers sit together, take the items that were presented and decomposed earlier, and do three things to them.

• Clarify — anything still ambiguous gets pinned down, and acceptance criteria 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 poker 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 sizes (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 sprint on refinement. For a two-week sprint that 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

At the end of the sprint the team shows what it built. 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?"

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.

All the ceremonies at a glance

Here is the whole set in one place. The right-hand column marks which ones are part of the official Scrum Guide and which ones real teams add — a distinction worth knowing before an interview or an audit.

Add those up for a two-week sprint and the ceremonies come to roughly ten to twelve hours per person — around fifteen percent of the sprint. That is the real cost of Scrum, and it is worth stating plainly. It buys you problems surfacing in days instead of months, but a team that adds meetings beyond this set should be able to say which question each new one answers.

The three roles

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

  Helps the team work effectively. Removes obstacles, protects the sprint from interruption, coaches. 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.

The three artefacts

An artefact in Scrum is simply a thing the team keeps and looks at. There are three, and each one carries a commitment — a companion statement that turns a list into something measurable.

The Definition of Done deserves a moment on its own, because it 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 to staging, documentation updated — whatever your team genuinely requires. If it is not written down, "done" means something slightly different to each person, and that difference surfaces at the worst possible moment.

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.

How this shows up in real delivery

If you want to judge a Scrum team quickly, do not ask about velocity. Ask any developer to state this sprint's goal without opening the board. A team that cannot has a list of tasks and a set of meetings, but it does not have a sprint — the goal is the thing that makes a sprint more than a fortnight of work.

Where it degrades

• A Definition of Done that stops short of deployable, 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.

When to use it

Related pages

• ManagementAgileAgile is a way of building software that assumes you will be wrong about something and plans for finding out early. Agile is not a process you install and not a set of meetings — it is a small group of beliefs, written down in 2001, that a dozen different methodologies are built on top of. This page explains those beliefs, all twelve principles behind them, and what actually changes in a team that takes them seriously.
• ManagementKanbanKanban is a way of managing work that starts from the process you already have and improves it under measurement. Kanban adds no roles and no sprints. It adds one rule — a cap on how many things you may work on at once — and that single constraint is what makes everything else in the method work. This page covers the board, the metrics, the seven regular meetings the method defines, and how to set that cap in practice.
• ManagementScrumbanScrumban is Scrum's rhythm with Kanban's pull mechanics. You keep the planning cadence and the retrospective, drop the sprint commitment, and refill the board when it runs low instead of on a calendar. Most teams that say "we do Scrum, but flexibly" are describing this — and naming it properly is what turns a quiet erosion of Scrum into a deliberate design.