Sprint Backlog in Scrum: A Plan Built Around the Sprint Goal

The sprint backlog is not a task list. Every sprint planning session produces a sprint backlog, and many of them are essentially task lists anyway: a collection of things to do during the sprint, distributed across team members, with hour estimates attached. This is better than nothing. It misses what a sprint backlog is for.

A genuine sprint backlog is the team’s plan for achieving the Sprint Goal. The distinction is critical. A task list tells you what each person will do. A sprint plan tells you how the team will accomplish something specific — and creates the framework for the team to adapt when reality differs from the plan.

Most teams create task lists and call them sprint backlogs. Then they wonder why sprint goals get missed and sprints feel like individual work periods rather than collective efforts.

Why Does a Sprint Backlog Need a Sprint Goal?

A sprint backlog without a Sprint Goal is just a container for work. The Sprint Goal is the reason the backlog items were selected — it defines what success looks like for the sprint independent of exactly which items get completed. The 2020 Scrum Guide makes the Sprint Goal the commitment for the Sprint Backlog: the Developers commit to the goal, and the goal leaves them flexibility in the exact work needed to achieve it.

Good sprint goals describe outcomes. “Users can complete checkout without contacting support” is a sprint goal. “Complete stories US-123, US-124, US-127, and US-131” is a scope list with no goal in it.

The goal matters most when things don’t go as planned (which is always). If mid-sprint the team discovers that story US-124 is going to take twice as long as estimated, a team with a clear sprint goal can ask: “Given we have a goal of enabling checkout completion, what’s the minimum set of stories we need to meet that goal?” They might cut scope while still meeting the goal. A team without a sprint goal just has a longer task list and less time — and typically ships less than expected.

Require a sprint goal. Write it on the board. Start every Daily Scrum by checking whether the team is on track to meet it; the Scrum Guide defines the Daily Scrum’s purpose as inspecting progress toward the Sprint Goal and adapting the Sprint Backlog as necessary.

What Should a Sprint Backlog Contain?

The Scrum Guide describes the sprint backlog as three things: the why, the what and the how.

The sprint goal — the coherent objective the sprint is aimed at. Everything else in the backlog supports this.

The selected product backlog items — the user stories, bugs, or features the Developers forecast they can complete. These should be refined before sprint planning, meaning they have clear acceptance criteria and the team understands what “done” looks like.

The team’s plan — how the team will deliver the selected items. This might be expressed as tasks, as a sequencing of work, or as specific technical approaches the team identified during planning. The guide calls the Sprint Backlog a plan by and for the Developers: they own it and update it throughout the sprint as they learn more.

What doesn’t belong in the sprint backlog: items added unilaterally by the Product Owner mid-sprint, items carried over from previous sprints without discussion, or work that isn’t connected to the sprint goal. If genuinely urgent new work arrives mid-sprint, the Developers and the Product Owner negotiate the scope of the Sprint Backlog openly, without endangering the Sprint Goal. Silently adding items hides the trade-off.

Who Updates the Sprint Backlog, and How Often?

The sprint backlog should be updated daily, by the developers themselves as their work progresses. The Scrum Master shouldn’t be reviewing what was done and updating it for them.

This sounds obvious and it’s rarely done. Most teams update their sprint boards during the standup — which means the board is always at least 24 hours stale. It also means the standup drifts into status reporting (“I worked on X yesterday, I’ll work on X today”). The useful version is planning: “we’re behind on Y, who can help?”

When the board is updated in real time, standups can focus on the actual question: are we on track to meet the sprint goal? If three developers are working on one story and two more are barely started, the board shows this. The standup conversation becomes about how to help — can someone from the fully-staffed story move over? Should we reprioritize?

Boards that show each developer’s queue but not the team’s collective state don’t enable this conversation. Design your board to answer one question first: are we meeting our sprint goal?

How Should You Structure a Sprint Board?

A sprint board organized around the sprint goal supports the right conversations. One pattern that works well:

Sprint goal visible at the top of the board.

Columns: To Do | In Progress | In Review | Done

WIP limits on In Progress (maximum active items equal to roughly team size minus one). This prevents the common failure mode of everyone starting something without anyone finishing anything. The idea comes from Kanban, where the Kanban Guide treats controlling work in progress as a core practice.

Acceptance criteria visible on each card — either printed on the card or one click away. If the acceptance criteria aren’t visible during standup, they’re not being used during standup.

Blocked items flagged prominently — a blocked card that isn’t labeled blocked is invisible in the standup, which means the blocker isn’t discussed, which means it stays a blocker.

Four Common Sprint Backlog Problems

Overloading the sprint: Teams take on more stories than they can deliver. Root cause is usually social pressure to appear capable rather than honest capacity assessment. Fix: track your actual velocity for three sprints and use that number in planning, not the optimistic version. The Manifesto’s principles ask for a pace the team can sustain indefinitely; a forecast built on optimism breaks it.

Stories that drag across sprint boundaries: Stories that are never quite done, carried from sprint to sprint, becoming lower and lower priority as the PO accepts the team will never close them. Root cause is usually insufficiently defined acceptance criteria or an unclear Definition of Done. Fix: return unfinished stories to the product backlog at the end of the sprint and re-plan them from scratch. The inconvenience of this process is the feedback mechanism that encourages better story sizing.

Sprint backlog disconnected from sprint goal: Team members work through the stories on the board without checking whether progress is tracking toward the goal. The sprint ends with several stories complete but the goal unmet. Fix: structure the Daily Scrum around the goal.

Invisible blockers: Work is stopped waiting for something or someone, but the board shows “In Progress.” Other team members don’t know help is needed. Fix: make blocked items visibly different from in-progress items. Discuss blocked items first in standup, before any other status.

A Sprint Backlog Exists to Coordinate the Team

The sprint backlog is a coordination tool. When it’s working, it’s helping the team make decisions in real time — who should work on what today? Where do we need to swarm? What should we drop if we’re running out of time?

When it’s not working, it’s a compliance artifact — evidence that planning happened, used to populate status reports, updated by the Scrum Master during standup.

The difference is whether the team actually uses the board to coordinate their work or whether they just use it to show someone else that work is happening. Teams in the first category consistently outperform teams in the second. That performance difference is the entire point of having a sprint backlog at all.