The Sprint Backlog: the Developers' plan, kept honest

On day two of a Sprint, a Developer finds that a task nobody listed is needed: the payment test account must be requested before anything can be tried. Where does that go? If the team's plan lives in a document that was frozen at planning, it goes nowhere. If the plan is a live Sprint Backlog, it goes on the board within the hour, and the Daily Scrum the next morning already knows.

What it contains

The Scrum Guide defines the Sprint Backlog as three things together: the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), and an actionable plan for delivering the Increment (how).

That makes it more than a list of tickets. The goal says why this Sprint matters, the items say what the team has forecast it can finish, and the plan says how the work will be done. Our post on the Sprint Goal covers the first part in more depth.

The Guide's description of the plan is specific. For each selected item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing the item into smaller work items of one day or less, and how it is done is at the sole discretion of the Developers.

Whose it is

The Sprint Backlog is a plan by and for the Developers. The Guide says it is a highly visible, real-time picture of the work they plan to accomplish during the Sprint in order to achieve the Sprint Goal.

Two consequences follow.

• Nobody else edits it for them. The Product Owner and Scrum Master can read it, ask questions about it and help the Developers think. They do not assign tasks into it. A Scrum Master who rearranges the board has taken over a Developer accountability.
• It is not a report. It exists so that the Developers can steer, and the Guide says it should have enough detail that they can inspect their progress in the Daily Scrum. If it is detailed for the benefit of a manager who wants to check on people, it has stopped serving its purpose.

It changes during the Sprint

The Guide says the Sprint Backlog is updated throughout the Sprint as more is learned. At the Daily Scrum, the Developers inspect progress toward the Sprint Goal and adapt the Sprint Backlog, adjusting the upcoming planned work. They may adjust the plan at other times too, since the Daily Scrum is not the only time they are allowed to.

There are limits on what can change. The Guide's rules for the Sprint say no changes are made that would endanger the Sprint Goal, quality does not decrease, and scope may be clarified and renegotiated with the Product Owner. If the work turns out to be different from what the Developers expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.

The SBOK® Guide is stricter about one point. In its process for updating the Sprint Backlog, it says that once the Sprint Backlog is finalised and committed to by the Scrum Team, new user stories should not be added. Tasks that were missed from the committed stories may need to be added, but new requirements that arise during a Sprint go on the Prioritized Product Backlog and are considered for a future Sprint. The Scrum Guide's phrasing allows renegotiation with the Product Owner, so the practical difference is one of emphasis. The SBOK treats a committed story as fixed and tasks as flexible, and the Guide treats the goal as fixed and the scope as flexible.

The SBOK also describes a Scrumboard that shows task status and is updated as the Sprint Backlog is, and a burndown or burnup chart: a burndown depicts the amount of work remaining in relation to the remaining time, and a burnup depicts what has been completed.

How much detail

This is the question teams argue about. The Guide's answer is functional: enough detail to inspect progress at the Daily Scrum. As a rule of thumb that is ours and not the Guide's, a task a Developer cannot finish in a day or less is probably too big to show progress on, and a task smaller than an hour is probably too small to be worth writing down.

Two failure modes:

• Too thin. Items with no tasks. The team learns about problems on day nine. The Daily Scrum has nothing concrete to inspect.
• Too heavy. Every step is a ticket with an estimate and a status, and updating the board takes more time than some of the tasks. People stop updating it, and it goes stale.

A reliable check is the Daily Scrum. If the Developers can look at the board and say whether they are on track for the Sprint Goal, it has enough detail.

Burn charts and forecasts

The Guide mentions burn-downs, burn-ups and cumulative flow diagrams as practices that help forecast progress. It adds that while they are proven useful, they do not replace the importance of empiricism: in complex environments what will happen is unknown, and only what has already happened may be used for forward-looking decisions.

A burndown for a Sprint is a drawing of the Sprint Backlog over time. If it is flat for three days, something is stuck, and the interesting thing is to ask what. If it falls to zero on day five of ten, the Sprint was under-planned, and the team can pull in the next item. What the chart cannot do is tell you whether the work is right.

A worked example

An invented, small case. A Developer team plans a Sprint with four stories and 22 tasks, each a day or less. The Sprint Goal is that a parent can book and pay for a lesson.

• Day one. All tasks are on the board, in To do. Dependencies are marked beside the tasks for the payment story.
• Day two. The missing test-account task appears, along with a note that it will take three days. The Developers move one payment task down and pull in a task from the profile story to keep busy. The Product Owner is told about the change, because it affects the order of delivery, not the goal.
• Day five. The burndown is above the line. At the Daily Scrum the team looks at which tasks are blocked and decides to simplify the cancellation story. They agree this with the Product Owner. The goal is untouched.
• Day ten. Three stories are Done, one has gone back to the Product Backlog. The board shows precisely why.

Nothing here is heroic. The board did what it is for: it let people see the situation early enough to act.

Common mistakes

• Freezing it at planning. A plan nobody updates describes an imaginary Sprint.
• Letting someone else run it. If the Developers do not own the board, it will be maintained for others' benefit.
• Adding new stories mid-Sprint. This endangers the goal. New requirements go on the Product Backlog.
• Mistaking tasks for the goal. All tasks done does not mean the Sprint Goal is met. Check the goal, not the board.
• Using it for individual monitoring. It shows the team's work. The Guide has the team, not any one person, accountable for the Increment.

The Agile Manifesto asks for processes that promote sustainable development, and a plan which reflects honest effort supports that.

How to practise it

The Sprint Backlog is easier to understand in action. In the simulator, developers claim tasks and the team freezes the Sprint baseline, then deals with a blocker on the board, a daily standup and a change request that arrives mid-Sprint.