The Sprint Backlog and the Increment

Why, what and how

The Sprint Backlog is composed of the Sprint Goal, the set of Product Backlog items selected for the Sprint, and an actionable plan for delivering the Increment — why, what and how. The half-answer naming only the selected items is the most common wrong option on this topic, and both missing pieces matter: without the Sprint Goal there is nothing protecting the Sprint from change, and without the plan there is nothing for the Developers to inspect their progress against each day.

It does not contain the Definition of Done, which is the Increment's commitment and a standard for the product rather than something agreed per Sprint. It also does not contain names against tasks. Decomposing work into pieces of a day or less is a technique Scrum mentions; allocating those pieces to individuals in advance is something Scrum does not do at all, because the Developers decide who does what, when.

A real-time picture changes, or it is not one

The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work they plan to do during the Sprint in order to achieve the Sprint Goal, carrying enough detail that they can inspect their progress at the Daily Scrum — and every clause of that description assumes it is updated throughout the Sprint as more is learned.

So a programme manager asking for the board to be restructured into the corporate reporting format and frozen after Sprint Planning is not raising a formatting question. A frozen board reports on a plan that stopped being true on the second day. Keeping a real working copy elsewhere is worse rather than a compromise: two versions of one artifact is the definition of low transparency, and the version the organisation reads is the one that is false. The need behind the request is almost always predictability, and Scrum answers that with a Done Increment every Sprint rather than with a board that holds still.

Changing the plan is the Developers' to do; changing what the Sprint will deliver is a conversation. When the work turns out to be different from what they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint, without affecting the Sprint Goal. Dropping a selected item on their own authority is the subtly wrong answer: the plan is theirs, but the items came out of a conversation about value with the person accountable for it.

An Increment exists the moment the Definition of Done is met

An Increment is a concrete stepping stone toward the Product Goal — the Product Goal, not the Sprint Goal, and that one-word swap is a distractor the exam offers deliberately. Each Increment is additive to all prior Increments and thoroughly verified so that they all work together, and the boundary is absolute: "Work cannot be considered part of an Increment unless it meets the Definition of Done."

Nothing in that description mentions the end of the Sprint or the Sprint Review, which is why a Sprint in which work met the Definition of Done on four separate days produced four Increments. They accumulate rather than supersede one another, the sum of them is presented at the Sprint Review to support empiricism, and any of them may go to stakeholders before the Sprint ends. The bar Scrum sets is that the Increment must be usable in order to provide value; being released is a separate decision, and it belongs to the Product Owner.