We might not be able to make Sprint Backlogs exciting, but we can make them more effective. Let’s look at what purpose they serve, and how to improve them.
What is a Sprint Backlog
A Sprint Backlog consists of a set of Product Backlog Items (PBIs) that the Developers think they can complete in the Sprint, along with the work needed, described in small enough chunks that progress can be tracked throughout the Sprint.
Creating the Sprint Backlog
Most Scrum Teams simply use whatever their online Scrum tool feeds them for their Sprint Backlog. This harms the Team’s capacity for engagement because it reinforces the sense that Scrum is happening to them, not something they choose. The Sprint Backlog is the Team’s plan for how to achieve the Sprint Goal they committed to for the Sprint. Since the Sprint Backlog is solely for the use of the Team to organize their own work, they are the only ones who create, change, and manage it — not a tool, and not an outsider.
When is it Created
The Sprint Backlog is an output of the Sprint Planning session at the beginning of each Sprint. However, it can – and should – be updated whenever something is finished, or an item is started. Since it is looked at in Daily Scrum, many teams update it there. The frequent visibility and review are intended to improve transparency and collaboration among team members.
The Scrum Guide doesn’t provide any guidance on the contents or format of a Sprint Backlog: “The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal.”
Since Teams are unique, there is no single correct practice that they all should follow. Teams choose and experiment with whatever helps them most to stay focused and self-organize, creating the Sprint Backlog with whatever methods work best for them, such as index cards, whiteboards, or, yes, even electronic tool. (Note, if having to maintain a tool for the Sprint Backlog slows down the Team, that is an impediment and it’s up to the ScrumMaster to help find a better solution.).
I have talked to Teams during the pandemic who have synchronized their expensive electronic tool with Mural or Miro. They use the free form whiteboard capability of these tools to meet their needs. Other Teams have exported data from the official electronic tools they use – Google JamBoard, a Google Sheet, etc. If it helps the Team improve collaboration and focus, then it is a good tool.
The Sprint Backlog is created by the Team, for the Team, so there are no set-in-stone rules. If your Team wants it to include a Dilbert comic, go for it.
That said, there are some things that people have found to be effective, so they’re worthwhile considering. Here are examples of a few Sprint Backlogs, to help inspire ideas.
Sprint Backlog Examples
To someone new to the Agile world the picture above may look a bit alien. Let’s break it down and make sense of it.
Swim Lanes and Columns
To keep the board organized visually, Teams use horizontal swim lanes and vertical columns to create a rough grid. At the front of a swim lane is their Product Backlog Item (or User Story). Then there is a series of columns moving left to right (instinctive to how we read English text), indicating progress of that Backlog Item through the Sprint.
Tasks – Yes or No
One specific, and often encountered belief, is that a Sprint Backlog must contain tasks, which is not the case at all. Tasks are not a required element of the Sprint Backlog. Some Teams only task on the fly, so they don’t note them in the Backlog. But if tasks are included, it’s recommended that they’re decomposed into parts small enough to be completed in a day or less, so that Team members can share tangible progress on a daily basis. If the PBIs are already very small – perhaps completed by two people in a couple of days – then breaking them down further into tasks is probably not productive.
In the above example image, the Team has elected to decompose their PBIs into tasks and use the Sprint Backlog to track them. They’ve chosen Tasks Not Started, In Progress, Task Complete, and then Story Accepted as their column headings.
“Finished” or “Complete” vs “Story Accepted”
If a Team does put tasks on the Sprint Backlog, they might find it helpful to create a boundary between tasks that the Team members themselves declare finished, and the Story/PBI being accepted by the Product Owner.
Bringing Retrospective into the Sprint
The Team here has also put a swim lane at the top for their actions or improvements that they committed to in the Sprint Retrospective. It’s at the top of the picture to act as a visual reminder that continually improving their process and Team is important. It’s recommended that the Developers include at least one action item from their previous Sprint’s Retrospective.
What’s the Goal
Finally, the Team in our above example has placed their Sprint Goal atop the Sprint Backlog as a visual reminder that it is the overarching goal of the Sprint, rather than just finishing individual tasks.
These additions encourage the Team to focus on more than just delivering a collection of User Stories. Instead, they’re achieving the Sprint Goal while making improvements that, in the mid-term, help increase their work quality and effectiveness.
This next Team has a slightly different view of the world, so it’s appropriate that their Sprint Backlog looks different as well.
The Team above has a product live in the field. They have added a swim lane to visualize Production Support work as a separate activity in their Sprint Backlog.
Real Life Examples
The above two examples are obviously graphics created to illustrate common Sprint Backlog structure. Here are some photos of actual Sprint Backlogs, and you can click on the smaller photos to open full-size images.
This Team has Expedite Lanes at the top, and column headings include “Challenge”, “Analysis and Planning” and “Unit Test”.
This is the Sprint Backlog of a marketing company, and they’ve elected to have a “Calls” Column to keep those separate from other Backlog Items. Other Columns are “To Do”, “In Progress” (with a “Waiting” section), “Complete”, “Reviewed”, and “Done”.
This Team has chosen columns for “WIP” (Work in Progress), “Ready for CR” and “In CR”, “Validate in Prod”, and “Closed in TFS”.
Some of these examples might have contents that make no sense to you, or your environment, and that’s okay. They don’t have to, because a Sprint Backlog has to only make sense for the Team that created it.
Other things you might try, based on what some Teams have found effective for them. Remember, your mileage may vary, so experiment and make it your own.
- Put tick marks on a card for every day it has been worked on and a ‘B’ for everyday it was blocked/stuck. This helps the team by providing information on how long individual work items took to complete, or how long they got delayed. Most teams discover that work items often spend longer waiting for something (approvals, another team, etc …) than they do getting worked on.
- Create a separate column for items that are Stuck/Waiting For/Blocked and make a note of the why. A separate “Waiting For” column visualizes the blockages in the system. Visualization makes them easier to measure, and attracts greater attention to resolve them sooner. After all, our teams don’t want to measure blockages, rather we want blocked items unblocked as soon as possible.
- Track Interruptions (e.g. management requests), requests for help from another Team… basically, track anything that causes the Team to lose focus on the Sprint Goal. These are usually tracked in their own lane. By tracking them, it highlights opportunities to work to reduce them.
- Create an Impediments area to track open and resolved impediments. This helps the team see where their problems are. During the retrospective, these impediments can make fodder for good discussion.
- Have a visual reminder of the Definition of Done on the boundary between Finished (for a task) and Accepted (for a User Story). This helps the team by making them think about the meaning of Done and therefore what level of quality is expected.
- Some teams that use Tasks find it useful to create task items that correspond to the Definition of Done. Other teams find that keeping the Definition visible at all times is a sufficient reminder.
- Hidden or Ghost work – Sometimes we discover that team members are working on things outside of the Sprint Backlog. On discovery in Daily Scrum (or any other time), make it visible. Many teams use the interruptions lane above, since this work from outside the Sprint Backlog is an interruption.
- Include a Calendar to note vacations, birthdays, special events, etc – anything that might affect the time available for work, as well as morale. Being reminded of our peers’ schedules and lives makes them more relatable. On a simple practical level, seeing a teammate’s upcoming vacation plans reminds us to address questions before they disappear, minimizing the number of items that get blocked by their absence.
- Consider noting any other events that affect the Team during the Sprint, e.g. an all hands meeting, other meetings, server outage, Zoom or MS Teams outage.
- Track mood, energy, etc using something as a simple as a spreadsheet view with people’s names in rows, calendar/weekdays across the top. On a daily basis, they mark happiness, satisfaction, engagement or some other simple measure, which will help document whether the Team’s energy or focus was negatively impacted.
All of the information that the Team tracks via the Sprint Backlog becomes data that should be brought into the Sprint Retrospective.
When your Sprint Backlog is designed and prepopulated by an outsider (or an electronic tool), it’s unlikely to contain any of these improvements that can help make the Backlog – and what it tells you – more effective and informative.
Working Through the Sprint Backlog
There is no required work order for items. Since the Scrum Team is truly self-organizing, they could work on the Sprint Backlog in whatever order they see fit. In practice, effective teams usually work from highest to lowest priority.
Fixed Scope or Variable Scope?
People get themselves tied up in endless knots on this subject – are the contents of the Sprint fixed (i.e. Fixed Scope) or can they change (Variable Scope)? These notes won’t settle all debates, but they should help reduce them.
- Sprint Goal – This shouldn’t change during the Sprint.
- Product Items committed to the Sprint – If the Sprint isn’t going well, the team might drop an item. On rare occasions when something important is discovered by the PO, the Scrum Team might accept a new PBI mid-Sprint. My normal recommendation is that they remove a larger existing item to accommodate the new item. I would expect the Team to discuss in their subsequent retrospective what happened and how to ensure that it doesn’t happen again.
- Task Items – Any amount of change is fine here since tasks aren’t officially part of Scrum. From experience, I find most Teams in Sprint Planning discover only about half of the tasks they wind up working on. So I would expect the task list to change on a daily basis. This is also a hint as to why most people think that Sprint Burndowns tracked in task hours are anti-pattern.
If change is made to the work in Sprint, it needs to come through the agreement and understanding of the team, not something imposed from the outside.
Forecasting with the Sprint Backlog
The Sprint Backlog is also the Developers’ forecasting tool. Each day during Daily Scrum, they replan their work and update the Sprint Backlog , using it to help them assess whether they’re on track to meet their Sprint Goal. If they realize that their Sprint Goal is in jeopardy, they work with the Product Owner on replanning.
In the past, Teams used to use a Sprint Burndown Chart that tracked task hours remaining to be done. Now, most of us would suggest that the focus on Tasks, versus focusing on User Stories/PBIs, is anti-pattern so we don’t recommend Sprint Burndowns. ScrumMasters everywhere, celebrate one less chart to update!
Many Teams benefit by stealing a page from the Kanban playbook and limiting Work in Progress, then including that in their Sprint Backlog structure. To sense whether they’re on track to meet the Sprint Goal, they simply look at the number of completed PBIs. If by the third or fourth day of a ten-day Sprint there isn’t at least one item finished, then it’s unlikely that the Team will get everything completed by Sprint end. By the sixth or seventh day, we would expect a Team to have at least half the items complete.
Teams that limit Work in Progress to only two or three Product Backlog Items at one time, tend to:
- collaborate more. They often discover practices like Behaviour Driven Development (or BDD) and Pair Programming. In the long run, these teams improve their throughput.
- cross-skill faster, since the bottlenecks become self-evident.
- eventually eliminate the problem of having unfinished work at the end of Sprint. If you limit WIP and you’re only a few days away from the end of the Sprint, then the team could swarm the remaining work one chunk at a time, making it likely that there will be no unfinished work at the end of Sprint.
So, used well, a Sprint Backlog combined with the Kanban WIP limit can solve challenges that many teams face.
Sprint Backlog vs Kanban Wall vs Product Backlog
While the Sprint Backlog is the Team’s plan for the Sprint, the Product Backlog is the Teams queue of work. So the funny thing is that the Sprint Backlog and Product Backlog have easily confused names, but vastly different meanings. In my workshops, whenever an attendee answers a question with, “Backlog”, my instant response is, “Which one?”
A Sprint Backlog is far more like the (better-named) Kanban board. A Kanban board is a visual control system from the world of Kanban. It combines the Product Backlog with the Sprint Backlog. The key difference between Scrum’s Sprint backlog and Kanban’s board is that Kanban has a Work In Progess Limit. As you’ve already seen, I strongly recommend Scrum Teams steal a leaf from the Kanban world and do this.
Sprint Backlog Anti-Patterns
(aka Avoid Doing These)
When the Sprint Backlog is created during Sprint Planning, some teams decide who will work on which PBI or task. When it’s kept to only one item, this isn’t bad, however when all items are pre-assigned to team members, we have just planned for the first bottleneck.
One Person Doing Many Things
This happens when Team Members are signed up for one than one task or PBI at the same time. We can’t multitask like we think we can because our brains just haven’t evolved to do this. The more we multitask, the less we get done overall. So when Team Members sign up for more than one task at a time, they’re promising to get less done. Exception: if a team member has one item stuck in Blocked (or Waiting for), they might start work on another. If it happens again, the team should look into why one person’s work is so frequently blocked. Alternative: when a team member has a item blocked, they might pair with another team member to help that person through the item.
The Sprint Backlog loses its value if used for external purposes like reporting, or for micro-management. When leadership uses it to look over the shoulders of the people doing the work — even if it’s not to direct the Development Team’s actions — it often leads to overloading the Sprint Backlog with details that undermine and eliminate transparency.
Since Scrum is about adapting to the evolving work, it is pointless to plan which items will go into the Sprint Backlog beyond the current Sprint, so we shouldn’t try to create Sprint Backlogs in advance. I think this happens because some of the popular electronic tools make it possible and people assume, based on the tool, that this is a good practice.
When people come from a traditional world into Scrum, some try to use the Sprint Backlog as a tool to recreate the phases they’re used to. For example, they create columns in their Sprint Backlog for Analysis; Design; Development; Test. While strictly speaking legal, they’re recreating the boundaries between traditional roles, making collaboration less likely and ensuring handoffs between team members. As mentioned in the Limiting WIP segment, effective Teams work collaboratively through the Sprint to get a PBI to complete before moving onto the next.
At the end of the Sprint, the Sprint Backlog is finished, completed work is deployed, and incomplete work is returned to the Product Backlog wherever the Product Owner deems it belongs. In the next Sprint Planning, a new Sprint Backlog is created.
Good Teams know that they own this. Great Teams experiment every few Sprints to find what they can do to make their Sprint Backlog even better.
See Also: Sprint Backlogs
Still Unsure How to Create an Effective Sprint Backlog?
Consider attending one of our Certified ScrumMaster workshops, where we discuss the how and why of Scrum, not just the what. You’ll get hands-on practical experience, and learn about some of the challenges – and solutions – along with tips on how to help your Team learn and grow to realize their potential.
 This term describes work done out of sight of the team. It is also sometimes referred to as “dark work” (as in done in the dark), but “Hidden” or “Ghost” work is more culturally sensitive.
 Github did a Developer Good Day survey and discovered that the more meetings someone is involved with, the less work they get done. My strong recommendation is that your only meeting most days should be Daily Scrum.
 These are called Niko Niko boards and not everyone thinks that they’re a good idea.
 This isn’t a hard and fast rule. Instead, it’s a pattern. As ScrumMaster or Agile Coach, if you see that the board is hinting at a problem, use that hint and look further to understand what is going on.
 “Scrum Anti-Patterns: Micromanagement”
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
Leave a Reply