Scrum is a way for a team to work through a big, messy project in short, fixed blocks of time called sprints. Each sprint ends with working software to show and a chance to change course, so the team never spends months building the wrong thing.
Why work in sprints
A project like 'build the game, fix the bugs, add a feature, ship the app' is hard to plan in one go. Requirements change while you build, and problems only show up late. Scrum is an Agile framework: instead of planning everything up front, the team plans a little, builds a little, checks the result and adjusts.
A sprint is a fixed time box, usually one or two weeks. The Scrum Guide, the official definition of Scrum, caps it at one month. The length stays the same from sprint to sprint, which gives the team a steady rhythm and makes it easier to see how much it usually gets done.
Short sprints also limit the damage. If a feature turns out to be the wrong idea, the team has lost two weeks of work on it.
Scrum rests on three ideas the Scrum Guide calls transparency, inspection and adaptation: make the work visible, look at it often, and change what isn't working. Every event in a sprint is a chance to do one of those.
Who is on a Scrum team
A Scrum team is small, typically 10 people or fewer, and has three accountabilities:
- Product Owner: decides what is most valuable to build next and keeps the product backlog in order. This is one person, so priorities have a single owner.
- Scrum Master: helps the team use Scrum well and gets blockers removed. They coach the team rather than hand out tasks.
- Developers: everyone who builds the product, including testers and designers. They decide how the work gets done.
The backlog and the sprint goal
The work lives in three places:
- Product backlog: an ordered list of everything the product might need, from features to bug fixes. Items near the top are detailed; items further down can stay rough.
- Sprint backlog: the items chosen for this sprint, plus the team's plan for finishing them.
- Increment: the finished, usable work at the end of the sprint. 'Finished' means it meets the team's Definition of Done, for example reviewed, tested and merged.
Every sprint also has a sprint goal: one sentence saying why the sprint matters, such as 'Players can save and resume a game'. When details change halfway through, the goal is what the team steers by.
How a sprint runs
Every sprint follows the same events, in the same order:
- Sprint planning, on the first day.
- The daily scrum, every day.
- The sprint review, at the end.
- The sprint retrospective, straight after the review.
Then the next sprint starts, with no gap in between.
Sprint planning
The team chooses what it will finish this sprint, which means the few most important items it can realistically complete rather than the whole backlog. The Product Owner brings the priorities, and the Developers say how much fits, based on how much they finished in past sprints. Planning ends with a sprint goal and a sprint backlog.
The daily scrum
The daily scrum is a 15-minute meeting, held at the same time each day. A common format is three questions for each person:
- What did you do since yesterday?
- What will you do next?
- Is anything blocking you?
The current Scrum Guide no longer requires that format. The point is to check progress towards the sprint goal and adjust the day's plan. A blocker gets raised here, then solved afterwards by the people who can fix it.
Protecting the sprint
Once the sprint starts, the plan holds. A new idea or request goes onto the product backlog for a later sprint. As the team learns more, it can clarify or renegotiate the details of its work with the Product Owner, but nothing that puts the sprint goal at risk. If the goal stops making sense, say because the company drops the feature, the Product Owner can cancel the sprint. That should be rare.
This rule is what stops a team from chasing every new request. Constant interruptions are how teams end up busy all sprint and finish nothing.
Sprint review
At the end of the sprint, the team shows what it built to its stakeholders, the people who will use or pay for the product. Ideally that means working software on a real device. The review is a working session: stakeholders react, and the Product Owner updates the product backlog with what everyone learned. The review inspects the product.
Sprint retrospective
The retrospective inspects how the team works. The team asks what went well, what went badly and what it should do differently next time. It picks one or two concrete changes and builds them into the next sprint. The retrospective is the last event of the sprint; then a new one begins.
A worked example: one two-week sprint
A team of five is building a recipe app. The top of the product backlog reads: search by ingredient, fix a crash on login, save favourites, dark mode.
Sprint planning is on day 1. Users keep saying they can't find recipes, so the sprint goal is 'Users can find a recipe by ingredient'. The Developers take ingredient search and the login crash, since nobody can search if they can't sign in. Favourites and dark mode stay on the backlog.
By day 4, search is stuck, and one developer says so at the daily scrum: the recipe database has no index on ingredients. After the meeting, the Scrum Master gets the developer who knows the database to pair with them.
On day 6, marketing asks for a holiday banner 'just this week'. The Product Owner adds it to the product backlog for the next sprint, and the team carries on.
The sprint review falls on day 10, and the team demos ingredient search on a phone. A stakeholder notices that typing 'tomatoes' finds nothing while 'tomato' works. That becomes a new backlog item.
In the retrospective that afternoon, the team notes that the login fix took three days because nobody could reproduce the crash locally. It agrees to add better logging next sprint, so the next crash is quicker to trace.
The next sprint starts with planning the following morning.
Scrum, Kanban and other approaches
Scrum is one of several Agile ways of working, which our development methodologies video compares. The other one you will meet most often is Kanban. Kanban has no sprints: work flows continuously across a board, with a limit on how much can be in progress at once.
Scrum suits product work that can be planned in short batches and shown off at the end. Kanban suits a steady stream of unpredictable requests, such as support tickets or operations work. Plenty of teams mix the two, running sprints with a Kanban-style board.
When Scrum doesn't fit
- A support or on-call team works from interruptions, so it can't fix its plan for two weeks.
- For a team of one or two people, the meetings can cost more than they save.
- If the requirements are well understood and won't change, frequent replanning adds little.
- If nobody can make the call on priorities, sprint planning stalls.
Common mistakes
- Status-report standups: the daily scrum turns into each person reporting to a manager and runs for 45 minutes. It is for the Developers to plan their day.
- Overfilling the sprint: planning more than past sprints show the team can finish means half the work rolls over every time.
- Changing scope mid-sprint: letting new requests in breaks the sprint goal and makes the review meaningless.
- Skipping the retrospective: busy teams drop it first, or hold it and never change anything.
- 'Done' that isn't done: counting untested or unmerged work as finished hides problems until later.
Key takeaways
- Scrum breaks a big project into sprints, usually one or two weeks long.
- Each sprint runs planning, a daily scrum, a review and a retrospective.
- The review inspects the product; the retrospective inspects how the team works.
- New requests go onto the product backlog, not into the current sprint.
- The Product Owner decides what to build, and the Developers decide how.
