The word “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.
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.
But even within agile circles, the term causes problems because there are two types of backlogs — the Product Backlog and the Sprint Backlog.
Most folks use “backlog” interchangeably to refer to either type. However, the majority of people think first of the “Product Backlog”, where all ideas for future work are stored and prioritized according to the value they are expected to bring.
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’s Purpose
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:
- The Sprint Goal, which informs the objective of the Sprint.
- The work items selected for the Sprint – usually in the form of user stories – that help achieve the Sprint Goal.
- An actionable plan for delivering work items, often listed as smaller tasks that contribute to the larger ones.
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 the Sprint Backlog to get a real-time picture of what the team plans to accomplish during their Sprint and the current status of their work.
Sprint Backlog vs Product Backlog: What’s the difference?
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 in your Sprint Backlog, but also the user stories and acceptance criteria in each Sprint Backlog item).
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!).
How to create a Sprint Backlog during Sprint Planning
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:
- Fit within a Sprint.
- Have an estimated size.
- Include a clear and detailed description.
- Be DEEP (Detailed, Estimated, Emergent, and Prioritized).
The agenda for Sprint Planning roughly looks like this:
- Set a coherent Sprint Goal.
- Select work items that help achieve the Sprint Goal.
- Review the Sprint Backlog to ensure the right amount of work has been forecasted.
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.
One way of ensuring the Sprint Backlog’s scope is reasonable is 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 Sprint 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!
Updating the Sprint Backlog during Sprints
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 the scope of the Sprint Backlog as long as it does not affect the Sprint Goal.
Strong Scrum practices foster an effective Sprint Backlog
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.
To paraphrase baseball legend Yogi Berra: If you don’t have a Sprint Goal, your Sprint Backlog might not get you there.