Sprint Backlog

Close

The Sprint Backlog is the Developers’ plan for achieving the Sprint Goal.

It includes the Sprint Goal, the Product Backlog items selected for the sprint, and the work Developers believe is needed to create a done increment.

The Sprint Backlog is one of Scrum’s three artifacts. It makes the current sprint plan visible so Developers can inspect progress, adapt their work, and coordinate throughout the sprint.

Who This Page Is For

This page is for Scrum Teams that want the Sprint Backlog to be a useful working plan rather than a static task list.

It is especially useful for:

  • Developers creating and adapting their sprint plan
  • Product Owners who want to understand how selected Product Backlog items become sprint work
  • Scrum Masters helping teams avoid treating the Sprint Backlog as a contract
  • Teams that overcommit, carry work over, or discover too much late in the sprint
  • Leaders trying to understand what should and should not change during a sprint

What This Page Covers

This page explains what the Sprint Backlog is, who owns it, what belongs in it, how it changes during the sprint, and how it differs from the Product Backlog.

It also covers common Sprint Backlog problems, including frozen plans, task lists that replace collaboration, and new product work sneaking into the sprint.

What Is a Sprint Backlog?

The Sprint Backlog is the plan Developers use during the sprint.

It includes:

  • The Sprint Goal
  • The Product Backlog items selected for the sprint
  • The work Developers plan to do to create a done increment

The Sprint Backlog is created during Sprint Planning and evolves during the sprint.

A simple Sprint Backlog might include selected Product Backlog items and a short list of tasks for each. Another might use a Scrum board, spreadsheet, agile project management tool, or other format. The tool matters less than whether it helps Developers coordinate and adapt.

The Sprint Backlog Belongs to Developers

Developers own the Sprint Backlog.

The Product Owner explains priorities, goals, and Product Backlog items. The Product Owner clarifies what matters and why. But Developers decide how much work they believe they can complete and how they will organize the work.

This matters because Developers are closest to the work.

Developers create the plan, update the plan, and use the plan to coordinate each day. The Sprint Backlog should be useful to them, not merely a reporting artifact for someone else.

The Sprint Goal Is Part of the Sprint Backlog

The Sprint Backlog is not just a list of tasks.

The Sprint Goal gives the plan purpose. It helps Developers and the Product Owner make tradeoffs when the sprint does not go exactly as expected.

If work is harder than expected, the Scrum Team can ask, “What adjustment best protects the Sprint Goal?”

Without a Sprint Goal, the Sprint Backlog can become a disconnected list of things to finish. With a Sprint Goal, Developers have a better basis for adapting the plan.

The Sprint Backlog Emerges During the Sprint

A Sprint Backlog should change during the sprint.

Developers will learn things. They may discover new tasks, remove unnecessary tasks, change estimates, pair on difficult work, or decide a different approach is better.

That is normal.

No one should expect Developers to identify every task during Sprint Planning. Complex work reveals details as it unfolds. The Sprint Backlog should capture useful changes so the plan remains visible and current.

Updating the Sprint Backlog is not a sign that planning failed. It is a sign that Developers are learning.

Adding Tasks Is Not the Same as Adding Scope

During a sprint, Developers may add tasks or steps they did not identify during Sprint Planning.

That is different from adding new Product Backlog items to the sprint.

For example, Developers may discover they need an additional test, a migration step, a design conversation, or a technical task. Adding that work to the Sprint Backlog helps the plan stay accurate.

But new product functionality should usually go into the Product Backlog. If new work threatens the Sprint Goal or materially changes the sprint, the Product Owner and Developers should discuss the tradeoff explicitly.

Sprint Backlog vs. Product Backlog

The Product Backlog and Sprint Backlog are related, but they serve different purposes.

The Product Backlog is the Product Owner’s ordered list of possible future work for the product.

The Sprint Backlog is the Developers’ plan for the current sprint.

A simple way to think about it:

  • The Product Backlog answers, “What might we do next for the product?”
  • The Sprint Backlog answers, “What are we doing this sprint, and how do we plan to do it?”

The Product Owner is accountable for the Product Backlog. Developers own the Sprint Backlog.

Sprint Backlog and the Daily Scrum

Developers often use the Sprint Backlog during the Daily Scrum.

That may mean looking at a Scrum board, reviewing blocked work, checking progress toward the Sprint Goal, or deciding what needs attention next.

The Daily Scrum should help Developers inspect progress and adapt the plan. The Sprint Backlog gives them something concrete to inspect.

If the Sprint Backlog is out of date, the Daily Scrum may turn into vague status reporting. If the Sprint Backlog is current and visible, Developers can have a better conversation about what to do next.

Sprint Backlog and Burndown Charts

Some Scrum Teams use a sprint burndown chart to show work remaining during the sprint.

A burndown chart can help Developers notice whether work is moving as expected. But it should not replace conversation and judgment.

If the chart is not moving as expected, the useful question is not, “Who is behind?” The useful question is, “What are we learning, and what should we do next?”

A Sprint Backlog should help Developers adapt, not pressure them into pretending the plan is still accurate.

Common Sprint Backlog Problems

The Sprint Backlog Is Treated as a Contract

A Sprint Backlog is a plan, not a contract.

Developers should update it as they learn. Treating the plan as fixed discourages transparency and adaptation.

The Sprint Backlog Is Created for Reporting

The Sprint Backlog should help Developers coordinate.

If it exists mainly so someone outside the Scrum Team can track individual status, it will not serve its real purpose.

Tasks Replace Collaboration

A task list can make work visible, but it can also encourage people to work separately.

Developers still need to collaborate around finishing Product Backlog items and achieving the Sprint Goal.

New Product Work Sneaks In

New product ideas should usually go into the Product Backlog.

If they are urgent enough to affect the current sprint, the Product Owner and Developers need to discuss the impact on the Sprint Goal.

The Sprint Backlog Is Not Updated

An outdated Sprint Backlog stops helping.

Developers should update it when they learn something important, discover new work, complete work, or change the plan.

The Sprint Backlog Has No Clear Sprint Goal

Without a Sprint Goal, the Sprint Backlog becomes a list of work.

The Sprint Goal helps Developers decide what matters most when adjustments are needed. For more detail, see The Goal of Sprint Planning.

Is Your Sprint Backlog Useful?

Use these questions to inspect the Sprint Backlog:

  • Does it include a clear Sprint Goal?
  • Does it show the Product Backlog items selected for the sprint?
  • Does it help Developers see what work remains?
  • Do Developers update it as they learn?
  • Is blocked or risky work visible?
  • Does the Sprint Backlog support the Daily Scrum?
  • Are Developers using it to coordinate, not just report status?
  • Is new product work handled through the Product Backlog unless the Sprint Goal is renegotiated?
  • Does the Sprint Backlog help the Scrum Team create a done increment?

Use the answers to find the next conversation Developers need to have.

FAQ

What is a sprint backlog?

The Sprint Backlog is the Developers’ plan for achieving the Sprint Goal.

It includes the Sprint Goal, the Product Backlog items selected for the sprint, and the work Developers believe is needed to create a done increment.

Who owns the sprint backlog?

Developers own the Sprint Backlog.

The Product Owner explains priorities and clarifies Product Backlog items, but Developers decide how to organize and adapt the work during the sprint.

Can the sprint backlog change during the sprint?

Yes. The Sprint Backlog should change as Developers learn.

Developers may add tasks, remove tasks, update estimates, or change the plan. That is different from adding new Product Backlog items without discussing the impact on the Sprint Goal.

Is the sprint backlog a task list?

It may include tasks, but it is more than a task list.

The Sprint Backlog includes the Sprint Goal, selected Product Backlog items, and the Developers’ plan for creating a done increment.

How is the sprint backlog different from the product backlog?

The Product Backlog is the ordered list of possible future work for the product.

The Sprint Backlog is the Developers’ plan for the current sprint.

Should the Scrum Master update the sprint backlog?

Developers should own and update the Sprint Backlog.

A Scrum Master may coach the Scrum Team on making work visible, but the Sprint Backlog should not become the Scrum Master’s reporting artifact.