The value stream

Sprint Planning and the Sprint Backlog

At the start of each Sprint, the Scrum Team meets to decide what it wants to achieve and how it intends to go about it. The result is a goal and a work plan that belongs to the Developers, the Sprint Backlog. This article presents the five patterns from A Scrum Book that describe this meeting, this plan and the freedom left to the Developers to order it.

A planning Monday

The career fair. At a lower secondary school, five people are preparing the career fair for the final-year students (aged 14 to 15): three homeroom teachers, the school librarian and the senior pastoral officer. They work in two-week periods, and the assistant principal decides the order of the topics. This Monday, they have two hours ahead of them.

The assistant principal presents the three topics at the top of her list: confirmed speakers, the workshop schedule and student registration. The team first formulates a goal: "By Friday the 21st, every final-year student knows the three workshops they will attend." It then breaks down each topic. "Confirmed speakers" becomes: follow up with the seven professionals who have not replied, find two possible replacements and book six rooms with the business office. By the end of the meeting, eighteen sticky notes are on the board in the teachers' lounge. Each represents at most one day of work.

This meeting contains everything Scrum calls Sprint Planning. The two-week period is a Sprint. The assistant principal's list is the Product Backlog, and she herself plays the role of Product Owner, accountable for the value of the result. The other five are the Developers, in the broad sense Scrum gives to the word: the people who do the work. Together with the Product Owner and a Scrum Master, who helps the team apply the method well, they form the Scrum Team. The eighteen sticky notes form the Sprint Backlog. In A Scrum Book (2019), Jeff Sutherland, James Coplien and their co-authors describe each of these elements with a pattern, that is, a proven solution to a recurring problem.

Sprint Planning, from Product Backlog to work plan

The Sprint Planning pattern starts from an observation: Product Backlog items represent only potential value as long as nobody has built them. Yet it is not enough to take the first ones on the list in order. They are not all the same size, and the whole must fit within the length of the Sprint. The Developers sometimes know that it is cheaper to build one item before another. Finally, designing each item in detail long in advance would be wasteful, since the context changes, but a minimum of design is needed before starting.

The solution is for the Scrum Team to meet at the start of each Sprint to plan the value it will create. It agrees on a Sprint Goal, then builds a plan that says what the Developers will build and how. The pattern lists four activities: checking that the items at the top of the Product Backlog are ready, agreeing on the goal, choosing the items the Developers plan to deliver and planning how to build them. The authors note that most teams carry these out at the same time, because it is by working out how to do a piece of work that you understand its scale.

The pattern adds a few details. The meeting is time-boxed: as a benchmark, the authors give four hours at most for a two-week Sprint. If an item is not specified well enough for the Developers to break it down, they do not take it. Finally, the plan that comes out of the meeting is only a first version, which the Developers adjust every day at the Daily Scrum, their fifteen-minute daily check-in.

The Sprint Backlog and its items

The Sprint Backlog pattern (which the authors also call Sprint Plan) answers the following need: to steer their progress, the Developers must know at all times what remains to be done to reach the goal. Yet they only understand the work by breaking it down, that breakdown is already design, and their understanding remains incomplete at the start of the Sprint.

The solution is to build a work plan that covers everything the team must accomplish to reach the Sprint Goal. It belongs to the Developers: they create it, and they alone can change it. It is sized according to their velocity, that is, the amount of work they finished in recent Sprints. It evolves during the Sprint, as the Developers add, remove, split or merge items as they learn. The authors ask for it to be visible to everyone, for example on a board, and make the Scrum Master responsible for ensuring that nobody uses it to monitor the Developers.

The Sprint Backlog Item

The Sprint Backlog Item pattern (SBI) sets the grain of the plan. A Product Backlog item says what must be delivered. It does not say how to go about it, and it reveals nothing of the risks of building it. Committing to such an item on the strength of its value alone means risking the discovery, too late, that it takes up the whole Sprint. And a team that wants several people to work on the same item must first have agreed on its parts.

The solution is to break each Product Backlog item down into units of work, none of which should exceed what one person finishes in a day. These units can be tasks or intermediate pieces of the result. The authors recommend writing them in a few words on sticky notes, which serve as reminders of the discussions. The whole remains the collective responsibility of the Developers, and units discovered during the Sprint are added to it.

Group registration. Six developers are working on the registration website of a sports federation. Their average velocity over the last three Sprints is 25 points. With the Product Owner, they settle on this Sprint Goal: "A club can register a whole team for a tournament in one go."

They choose five items at the top of the Product Backlog: group registration (8 points), a single payment for the team (5), the confirmation email to the captain (3), an exportable list of entrants (5) and a display fix on phones (3). The total is 24 points, under the velocity of 25.

Then comes the breakdown into tasks of one day at most. It reveals that the exportable list requires reworking the data model: the Developers re-estimate it at 8 points, and the total rises to 27. They suggest to the Product Owner that the display fix, which does not serve the goal, be removed. The Sprint is back down to 24 points. The breakdown also shows that the single payment depends on a setting at the payment provider. The request goes out the same day.

The order of work belongs to the Developers

Once the plan is drawn up, it remains to decide in what order to carry it out. The Developer-Ordered Work Plan pattern discusses a widespread idea: following the order of the Product Backlog, so that the most important items are at least finished if the Sprint goes badly. The authors see two drawbacks in this. The habit establishes the idea that an unfinished Sprint is normal, and the Developers' forecast loses its value. It also gives the Product Owner an indirect way of directing the daily work, and the temptation to intervene in mid-Sprint when priorities change.

An argument from numbers adds to this. Ten tasks can be arranged in 3,628,800 ways. The authors take the example of a Sprint of five items each broken down into nine tasks: these 45 tasks allow 45! possible orders, about 1.2 × 10⁵⁶ (the book rounds to 2 × 10⁵⁶). Some orders make it possible to go fast, others do not, and the best one changes every day with obstacles and discoveries. Only those who do the work have the information needed to choose.

The solution is therefore to let the Developers decide the order of tasks that gives them the best chance of reaching the goal and completing the plan. The order of the Product Backlog informs them without constraining them, and they review their choice every day. The Product Owner keeps two means of influence: the Sprint Goal, which indicates what matters most, and the length of the Sprint. In an emergency, the Product Owner goes through the exception procedure described in the article Protecting the Sprint from interruptions. The authors point out the downside of this freedom: an order chosen carelessly leaves many items half done at the end of the Sprint. Their answer is swarming, which consists of finishing an item together before opening another.

Dependencies First: settling dependencies before mid-Sprint

The Dependencies First pattern deals with a specific risk: if critical dependencies are still open at the halfway point of the Sprint and the team is still discovering new ones, the Sprint is in danger. A dependency may be a supplier's delivery, a promised resource that is slow to arrive or an item waiting for another. The authors warn against putting these questions off until the "last responsible moment": "you often don't know when the 'last responsible moment' will arrive until it has passed."

The solution is to make sure that all known dependencies are under control by mid-Sprint. To do this, the team starts with the hardest tasks and with those where dependencies are likely to appear, so that surprises surface early. If the rule cannot be kept, the pattern offers two ways out: stopping the Sprint in order to replan, or falling back on the Sprint Goal.

At the school, this gives an obvious order of work. Following up with the speakers and booking the rooms are done on Monday and Tuesday, because they depend on people outside the team. By the Friday of the first week, five professionals out of seven have replied, and the team calls the two replacements. The workshop schedule can then be drawn up on a sound footing. Had the team started with the posters, it would have discovered the withdrawals three days before the fair.

What the 2020 Scrum Guide says

The Guide organizes Sprint Planning around three topics: why this Sprint is valuable, what can be done this Sprint, and how the chosen work will get done. The first was added in 2020.
The Guide limits the meeting to eight hours for a one-month Sprint, and expects it to be shorter for a shorter Sprint. The book's benchmark of four hours for two weeks is consistent with this rule.
The meaning of Sprint Backlog differs. In the 2020 Guide, it brings together the Sprint Goal, the selected Product Backlog items and the plan for delivering them. In the book, the term mainly refers to that plan. The Guide does not use the expression "Sprint Backlog Item", but it mentions breaking work down into units of one day or less.
The Guide confirms that how the items are turned into an Increment is up to the Developers alone, and that the Sprint Backlog is "a plan by and for the Developers".
The Guide allows the Developers to renegotiate scope with the Product Owner during the Sprint, as long as the goal is not affected. It writes "Developers" where the book says "Development Team".

Limits and pitfalls

The most common drift turns Sprint Planning into a distribution session: a manager assigns tasks to named people for two weeks. The plan no longer belongs to the Developers, and everyone protects their own list instead of aiming at the common goal.

Another drift consists of skipping the "how". The team chooses items until it reaches its velocity and closes the session. The Sprint Backlog is then just a copy of the top of the Product Backlog. The surprises that breaking down the work would have revealed appear in the second week, and the Daily Scrum has no plan to adjust.

The freedom to order the work does not entitle the team to ignore the Product Owner. The authors accept that experienced teams discuss the order with the Product Owner, provided the Developers agree to it. A meeting that regularly overruns most often signals that the items have not been prepared, which is a matter for Product Backlog refinement.

The thresholds cited (four hours, one day per task, mid-Sprint) come from the authors' experience and have not been established by comparative studies. The article Criticism and the state of the evidence explains the scope of this kind of recommendation.