What Is a Sprint Backlog?

Collaborators: Joel Bancroft-Connors, Ram Srinivasan. 

Teams practicing scrum use a sprint backlog, which is made up of the sprint goal, a collection of product backlog items forecasted to be completed in the sprint, and an actionable plan for delivering the sprint goal. 

There's a new sprint backlog for each new sprint. The sprint is one of the five events of the scrum framework. The sprint supports focus on the sprint goal and is a fixed length, with one sprint occurring immediately after the one before it. 

Terms to Know

Developers: Although this term sounds technology-oriented, developers are the people on the scrum team who create usable increments every sprint from a variety of industries involving complex work. It is considered an accountability distinct from the product owner or scrum master. 

Sprint goal: The single objective of the sprint. The sprint goal is a stepping stone toward the product goal.

Product backlog item (PBI): A single element from the product backlog, which contains the desired work, features, changes, or additions for the product or service.

Why Do Scrum Teams Use a Sprint Backlog?

A scrum team uses a sprint backlog to support focus on the sprint goal. The team develops a sprint goal to support concrete progress toward the product goal during the sprint. 

The sprint backlog is also one of the three scrum artifacts. The artifacts allow anyone to see the work and value to be delivered (sprint and product backlog) and already delivered (the increment). This transparency makes it possible to inspect the artifact and adapt when needed.

The developers on the scrum team can and do adapt the sprint backlog as needed during the sprint as conditions change. 

The sprint backlog is essential for providing transparency. The three empirical pillars of scrum are transparency, inspection, and adaptation, and the sprint backlog is one way to make key information visible for inspection, and adaptation if needed.

Adapting a Sprint Backlog

The sprint backlog may be updated multiple times a day, as plans can be updated as more is learned by the developers when doing the work. The sprint backlog MUST be adapted at least once a day to reflect the latest plans by the developers. 

During the sprint, the scope is negotiated between the product owner and the developers as more is learned. For example, the developers can choose not to complete the forecasted PBIs, and the developers can pull a new PBI into the sprint based on the discussions with the product owner.

This ability to adapt based on changes and new information is inherent to the scrum framework; however, a couple of things should not change during the sprint: the sprint goal and any changes that jeopardize the scrum team's ability to achieve the sprint goal.

When Do You Create a Sprint Backlog?

During the sprint planning event, the scrum team commits to a sprint goal — the "why" of their sprint. This is a single objective and a stepping stone toward the product goal. The product goal describes the future state of the product.

The developers on the scrum team select product backlog items to work on in the sprint — the "what." Finally, they decide "how" they will collaborate to complete work and achieve their goal.

These three things make up the sprint backlog:

• The "why": a sprint goal
• The "what": a forecasted subset of PBIs
• The "how": the developers' plan for doing the work

This plan is a plan made by the developers and for the developers. The product owner collaborates with the developers to figure out what work should be pursued, but no one but the developers can decide "how" to turn selected PBIs into valuable, usable increments.

The developers choose PBIs to add to their sprint backlog that will contribute to the sprint goal. They choose items that they believe they can complete within their sprint. The developers collaborate to complete the work of each PBI, and a PBI becomes an increment once it meets the definition of done.

Benefits of a Sprint Backlog

A defined sprint backlog helps teams maximize the value of the sprint by focusing on a sprint goal. The sprint goal gives the scrum team focus. They can look at the sprint backlog and know precisely the goal and how they can progress toward it. Managing work via the sprint backlog also helps ensure that the work creates value. 

Sprint backlogs improve ownership of work. Because the developers populate the sprint backlog together, they feel greater ownership over the plan. 

The sprint backlog improves transparency. Everyone can see the backlog and see where and how collaboration must happen to complete product backlog items.

User Stories: One Option for Representing PBIs in the Sprint Backlog

Although not a part of the scrum framework, user stories are one of many options for defining product backlog items. Other teams may have another way to break down work into smaller pieces or leave their items as PBIs. Regardless of how a PBI is written or expressed, the value and usefulness of the PBI should be clear to everyone.

Although optional, user stories can help create effective and focused sprint backlogs. The first purpose of user stories is to act as a placeholder for a conversation with the imagined user. The user story is a statement, often completed with this formula created by agile coach Rachel Davies:

"As a <role>, I want <action>, so that <value or justification>." 

There are many ways to write user stories. Experiment with different formats to see what works well. Another way to write a user story is:

In order to <benefit> as a <role/persona>, I want <feature/functionality>. 

A user story has one or more acceptance criteria that would be met when the user story is implemented. The user stories become the "what" of their sprint backlog. The developers then collaborate to decide how they will work on particular user stories. 

Some teams like user stories because of the customer focus. By keeping the story linked to the PBI, the story may help the team stay focused on what really matters: a product that delights customers and stakeholders. 

How to Make and Use a Sprint Backlog

Teams can experiment with different techniques for visualizing, sharing, and seeing the status of items on the sprint backlog. All the work the developers are doing is visible on the sprint backlog. The sprint goal the team commits to must be contained in a single place where everyone can see it, such as at the top of the sprint backlog.

Some scrum teams choose to use a scrum board with status columns, but there are many other ways to visualize a sprint backlog. Lists, spreadsheets, whiteboards, pictures — numerous tools can support your collaboration.

Who Creates the Sprint Backlog?

The developers, often collaborating with the product owner for additional information, populate the sprint backlog with product backlog items.

Scrum teams are empowered and self-managing. The team decides who does what work, how they do it, and how they'll provide value in service of their product goals. In the sprint planning event, developers should select the items for the sprint backlog. The entire scrum team collaborates to create a sprint goal, and the product owner may offer guidance about the relationship between PBIs and the sprint goal as needed. 

Realistic Planning in the Sprint Backlog

As developers select PBIs for the sprint backlog, they are predicting what they believe they can complete in the sprint based on the following:

• The effort involved with the work
• Their availability 
• Any absences on the team during the sprint
• Their past performance with similar items
• Skill dependencies to get the work done
• Other factors unique to the team and context

It's not a perfect science, and conditions will most likely change during the sprint, but the developers nonetheless forecast what they think they can accomplish to achieve their sprint goal, much like a weather forecast is not set in stone.

Optional techniques like size or story point estimation can help teams understand their capacity and construct realistic sprint backlogs. Sizing and estimation techniques are not part of the scrum framework, so your scrum team can choose any technique you all find helpful. The people doing the work — the developers — do the sizing.

To estimate the effort of work, teams may assign points, t-shirt sizes, pre-defined animals, shapes — anything the team understands as an indication of relative effort. Over time, the developers' estimation supports their ability to discuss capacity with each other and stakeholders.

Learn How to Unlock the Full Potential of Sprints

Explore Scrum Alliance certifications to find the path that's right for you. No matter your profession or your goals, there's a course that will equip you with the skills and resources to practice agility in a real-world context.