Sprint Backlog Essentials: What You Need to Know

The phrase Sprint Backlog can cause all kinds of confusion. An uninitiated boss, for example, overhearing their agile development team speak of their “large backlog”, could launch into a tantrum about their performance, interpreting the word “backlog” as an accumulation of overdue work.

But in Agile software development, the backlog refers to a location where teams store and prioritize product ideas and tasks they might work on in the future.

Even within agile circles, the term causes problems because there are two types of backlogs — the Product Backlog and the Sprint Backlog. While most teams understand the Product Backlog well, their understanding of the Sprint Backlog may be a little less clear.

This article explains how to create and maintain an effective Sprint backlog every Sprint:

The Sprint Backlog is a list of work an agile team intends to finish during a Sprint. Sprint Backlogs are used across various Agile frameworks, including Scrum and derivative frameworks such as Scrumban, Scrum of Scrums and LeSS.

The official Scrum Guide breaks the Sprint Backlog down into three components:

Many teams choose to also add size estimates for each task – in hours or story points – using Planning Poker to determine how many items they can fit in one Sprint.

A basic approach for creating a Sprint Backlog is using a spreadsheet. But most teams use a Sprint Board or Task Board – with columns for whether something is planned, in progress, stuck, or completed – in a backlog tool like Jira or GitHub.

The Sprint Backlog creates clarity and helps the team know what to focus on during each Sprint. Since Sprint Backlog items are often documented in a digital tool with their status – to do, doing, done – other stakeholders can also refer to it to get a real-time picture of what the team plans to accomplish during their Sprint and the current status of their work.

The Sprint Backlog belongs solely to the development team. The Product Owner works with the whole Scrum team to set the Sprint Goal, but the development team is responsible for determining which tasks help to fulfil that goal during the sprint.

Agile frameworks like Scrum put emphasis on giving the people closest to the work the most control over how that work gets done.

The Product Owner is accountable for effective Product Backlog management. This includes maintaining and prioritizing the Product Backlog, which contains Product Backlog Items (PBIs) – all the ideas a team could possibly work on to develop their product.

The Sprint Backlog belongs to the Developers and is made up of items they have selected from the Product Backlog to work on during a Sprint.

You can think about the Product Backlog as a map, with many attractive locations you could visit, but not in one trip (your Sprint). For each trip, you need to pick one destination (your Sprint Goal). To get there, you need a route (the Sprint Backlog) and turn-by-turn instructions (the work items comprising it, but also the user stories and acceptance criteria that make up your tasks).

If someone talks broadly about an “Agile Backlog,” ask them whether they’re referring to the Product Backlog or the Sprint Backlog. Likely, they mean the Product Backlog, but perhaps they don’t know the difference (in that case, send them this article!).

Agile teams create usually work together to create a Sprint Backlog during their Sprint Planning meetings. Team members select work items from the Product Backlog and move them to the Sprint Backlog. If you’re using a Kanban board, this comes down to moving items from the Backlog to the Todo column.

Before Sprint Planning starts, the Product Owner ensures relevant work items in the Product Backlog are ready for selection by doing backlog refinement.

This process ensures that the Product Backlog is appropriately prioritized and detailed.

As a loose rule each Product Backlog item should:

The agenda for Sprint Planning roughly looks like this:

Creating the Sprint Goal together with the Product Owner and Scrum Master is the first order of business during Sprint Planning. The Sprint Goal is your north star for deciding which items to move from the Product Backlog to the Sprint Backlog.

While the Scrum Guide is somewhat vague on this point, it’s generally understood that the Product Owner leads the creation of the Sprint Goal by bringing an objective to the Sprint Planning meeting.

For an example, check out Parabol’s open Product and Sprint Backlog here. 

This goal might then be refined, adjusted, and finalized as the entire team discusses the plan and selects items for the Sprint Backlog.

Scrum trainer Simon Kneafsey illustrates this process on Scrum.org, through the example of a bakery in the United Kingdom.

The Product Owner’s immediate product goal is to “launch a website that allows sales to customers inside London.” When discussed during Sprint Planning, the team agrees it will take several Sprints to complete this product goal, so they set the Sprint Goal for their first Sprint to create a basic website structure.

Once you’ve set the Sprint Goal, the team will select items that go into the Sprint Backlog that will help achieve the goal. In the bakery example, these could include drafting out three possible structures for the new website and testing those with several customers through visual mockups.

The team then lists the most critical smaller tasks related to those items to determine whether the work will fit into one Sprint.

You can ensure the backlog’s scope is reasonable by using agile metrics like Velocity, Cycle Time, or a Burndown chart to determine whether the amount of work your team have planned is realistic compared to your historical performance.

A Burndown chart visualizes a team’s progress during a Sprint and makes it easy to see whether you’re on track to hit your goal.

📌 Note: Don’t forget to add outcomes from previous Sprint Retrospectives as work items to your next Sprint if necessary. This practice ensures you’re continuously improving your work processes. Parabol‘s free retrospective tool has Jira and GitHub integrations to make the process of exporting retro action items to your backlog simple!

The Developers can change how they have planned their work during Sprints if that helps achieve the Sprint Goal or complete selected work items. However, no changes should be made that endanger the Sprint Goal.

Because Developers are accountable for making progress towards the Sprint Goal, Product Owners – or other stakeholders – can’t make adjustments. They should only set priorities and their vision at the next Sprint Planning meeting.

Developers should update the Sprint Backlog throughout Sprints as their understanding of and progress on specific work items evolves. These updates happen during the Daily Scrum, the purpose of which is described in the official Scrum Guide as: “to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.”

Common updates to the Sprint Backlog are adding or removing tasks from user stories and updating progress on task completion. When specific stories or other substantial work items cause unforeseen challenges, developers and the Product Owner may collaborate to adjust its scope as long as it does not affect the Sprint Goal.

Your Sprint Backlog is an essential Scrum artifact that you will set and refresh every cycle. Still, it’s only effective when you understand its purpose and follow other Scrum practices – setting a clear Sprint Goal, refining the Product Backlog, and giving ownership of the Sprint Backlog to the development team.

Without such processes, your Sprint Backlog becomes irrelevant as it ends up becoming a shared task list that anyone can throw work on at any time.