The Sprint Backlog is the Developers' plan for a single Sprint, and it carries three things at once. The Sprint Goal is the why, the set of Product Backlog items selected for the Sprint is the what, and an actionable plan for delivering the Increment is the how. Remove any one of the three and the plan stops being a plan. A set of items with no Sprint Goal leaves the Developers nothing to renegotiate scope against, and a Sprint Goal with no actionable plan leaves them nothing to inspect each day.
A plan by and for the Developers
The Guide calls the Sprint Backlog a plan by and for the Developers, and both halves of that phrase do work. The Developers make the plan, because the people carrying out the work are the only ones who know what it actually involves. The plan then exists to serve their own decisions, and its readers are the Developers themselves. When a manager treats it as a progress report, they are reading somebody else's working notes.
Almost every exam question on this artifact tests the same boundary, and three scenarios carry it.
- A manager assigns tasks to named Developers.
- A Product Owner inserts an item after Sprint Planning.
- A Scrum Master keeps the board tidy on the team's behalf.
Each of the three takes on something the framework places with the Developers, so the answer in each case names the Developers as the people whose plan it is.
The Developers select the items themselves
The items in the Sprint Backlog were chosen by the Developers during Sprint Planning. The Product Owner orders the Product Backlog and explains which items would most increase value, and the Developers then decide how many of those they can turn into a Done Increment. If the Product Owner wants six items on the mobile checkout and the Developers forecast four, four is what enters the Sprint Backlog.
That division is the reason a forecast means anything at all, because a quantity of work handed to a team is somebody else's guess about its capacity.
What may change and what may not
A forecast that may shift raises the question of what in the plan is fixed. The Sprint Goal is the commitment of the Sprint Backlog, and it holds for the whole Sprint. Everything else in the plan is expected to move. Scope may be clarified and renegotiated with the Product Owner as more is learned, so an item can be dropped once it turns out to be unnecessary and work can be added when the Developers find that the goal needs it.
The word worth noticing is renegotiated, because a renegotiation needs two parties and neither of them can settle it alone. The Product Owner cannot push work into the Sprint Backlog. Nor can the Developers quietly drop items the Sprint Goal depends on, since a change that endangers the Sprint Goal is the one change a Sprint does not allow.
Why the Sprint Backlog is updated every day
Changes of that kind have to land somewhere, and the plan is where they land. If a plan is written on the first morning and then left alone for two weeks, it has become a record of what the team once believed. The Sprint Backlog is meant to be a highly visible, real time picture of the work the Developers plan to accomplish, which means it is revised as they learn. A current plan is usable at the Daily Scrum, where the Developers inspect progress towards the Sprint Goal and adapt the plan for the coming day.
It follows that the plan needs enough detail to inspect progress against and no more. A note saying the migration script still needs a dry run against a copy of production is enough to inspect. An hour by hour breakdown of that dry run is detail the next day's learning is about to throw away.
What the Scrum Master does with the Sprint Backlog
A team that keeps its plan current to that level of detail is self-managing, and coaching self-management is the part the Guide gives the Scrum Master in this artifact. The Developers own the Sprint Backlog, so a Scrum Master who updates it, moves items for people or chases them for a status picture has taken over the self-management the accountability exists to build. The service is narrower than that. It amounts to asking why yesterday's plan went untouched, and to ensuring the Daily Scrum happens so the Developers have a point at which to change the plan themselves.
The commonest exam trap puts the Scrum Master between the Sprint Backlog and somebody outside the team. A manager may ask for a progress report, a Product Owner may want an item added mid Sprint and a stakeholder may ask who is working on what. All three are answered the same way, by pointing at an artifact that is already highly visible. Producing a separate report from it would make the Scrum Master the channel through which the plan is read, which is how a plan by and for the Developers quietly becomes a plan for somebody else.
What the framework does not say
Scrum does not require a board, a burndown chart, tasks, estimates in hours or any tool. Those are practices teams have found useful, and none of them appears in the Guide. The Guide requires only that the three parts exist, that the Developers own the plan and that it stays current enough to support daily inspection.
So a scenario describing a team with no task board is not describing a team doing Scrum wrongly. A scenario describing a Sprint Backlog nobody has touched since Sprint Planning is describing exactly that, because a plan left alone has stopped being a plan by the second day.