We might not be able to make Sprint Backlogs exciting,but we can make them more effective. Lets look at what a Sprint Backlog is, what purpose it serves, and how to create, manage, and improve it. What is a...
We might not be able to make Sprint Backlogs exciting,but we can make them more effective. Lets look at what a Sprint Backlog is, what purpose it serves, and how to create, manage, and improve it.
What is a Sprint Backlog?
ASprintBacklog is a list ofProduct BacklogItems (PBIs) that theDevelopersthink they can complete during the Sprint, along with the work needed, described in small enough chunks (e.g. User Stories) that progress can be tracked throughout the Sprint. These items are selected from the Product Backlog by the Scrum Team during Sprint Planning.
The Sprint Backlog is essential because it is the Teams clear plan for how to achieve theSprint Goalthat they committed to for the Sprint. The teams work is visible and updated on a daily basis to encourage transparency and collaboration within the team itself. By having a clear plan for the Sprint, it allows the team to focus and bring the highest value work to completion.
Who creates the Sprint Backlog?
The Scrum Team is responsible for creating the Sprint Backlog. Sadly, many Scrum Teamssimply use whatever their online Scrum tool feeds them for their Sprint Backlog. This harms the Teams capacity for engagement because it reinforces the sense that Scrum ishappening to them, not something thatthey choose.
Since the Sprint Backlog is solely for the use of the Scrum Team to organize their own work during a Sprint, they are the only ones who create, change, and manage it not a tool, and not an outsider.
When is the Sprint Backlog created?
The Sprint Backlog is created in theSprint Planningsession at the beginning of each Sprint. Prior to the start of the Sprint the Product Owner has prioritized the items and discussed them with the team (this is called Product Backlog Refinement). By doing it before Sprint Planning, the whole team better understand what theyre committing to. This collaborative effort ensures shared understanding and ownership of the Sprint Backlog. During the Sprint, the Sprint Backlog is updated by the Scrum Team when something changes, a task or Product backlog Item (PBI) is completed, or a new item is started.
How does a Sprint Backlog work?
After the Scrum Team creates the Sprint Backlog, the Developers (Scrums poor way of saying all the people who do work) break down the Product Backlog Items (PBI) into smaller size and estimating the work needed, the team works through the Sprint Backlog with each individual team member selecting PBIs to work on. This promotes autonomy and allows Developers to work on things they feel most comfortable with or have the necessary expertise in. As a PBI is completed, the Scrum Team updates the Sprint Backlog to reflect that. There is no required work order for items. Since theScrum Teamis trulyself-organizing, they could work on the Sprint Backlog in whatever order they see fit, but effective teams usually work from highest to lowest priority.
How should the Sprint Backlog be managed?
Since we look at the Sprint Backlog duringDaily Scrum, most Scrum teams update it there. The frequent visibility and review are intended to improve transparency and collaboration among team members. No one is assigned work in Scrum, instead, team members have the freedom to choose what they want to work on themselves, so any team member may update a Sprint Backlog item. They might mark it as done, or as needing feedback from the Product Owner, etc. If a particular item in the Sprint Backlog is confusing:
it should not be brought into the Sprint and, instead, turned into a conversation at the next refinement session, or it can be turned into a Spike a timeboxed investigative effort to better understand the problem, or t can be committed pending further clarification right after Sprint Planning. (This is a common practice and is almost always a bad idea. Options 1 and 2 are better choices).A Sprint is dynamic and evolves so the Sprint Backlog changes as the Sprint moves along. The Sprint plan that helped you start the Sprint often doesnt last the whole Sprint. Did the team realize that a User Story (aka PBI) wont be completed this Sprint? Remove it and tell the Product Owner. Hit by a product support defect mid-Sprint? Add the emergency fix to the Sprint Backlog, or put an existing item on hold and swarm the defect. (Hint: if this is a frequent problem, weve covered reducing the Production Support burden in this Scrum By Example entry).
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 wont settle all debates, but they should help reduce them.
Sprint Goal This shouldnt change during the Sprint. Product Items committed to the Sprint If the Sprint isnt 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 doesnt happen again. Task Items Any amount of change is fine here since tasks arent officially part of Scrum and the task list can change on a daily basis.If change is made to the work in Sprint, it needs to come through the shared agreement and collaborative understanding of the team, not as something imposed from the outside.
What are the characteristics of a Sprint Backlog?
The Scrum Guide doesnt provide any guidance on the structure 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.[1]
Since Teams are unique, there is no single correct practice that they all should follow when creating a Sprint Backlog. Teams choose and experiment with whatever helps them most to stay focused andself-organize, creating the Sprint Backlog with whatever methods work best for them, such as index cards, whiteboards, or, yes, even electronic 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 XKCD comic, go for it. That said, there are some things that people have found to be effective, so theyre worthwhile considering.
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 (e.g. User Story or task). 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.
When teams transition from traditional project management methods, they might be tempted to use the Sprint Backlog to recreate familiar phases such as Analysis, Design, Development, and Test. Teams do this, but it misses the collaborative nature of Scrum and introduces unnecessary handoffs between team members.
Example Sprint Backlog 1:
To someone new to the Agile world the picture above may look a bit alien. Lets break it down further and make sense of it.
Does a Sprint Backlog have tasks yes or no?
Tasks are not a required element of the Sprint Backlog. If tasks are included, its recommended that theyre 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.
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 User Story/PBI being accepted by the Product Owner.
Work in Progress
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 theyre 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 isnt at least one item finished, then its 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.[3]
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 youre 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.
Bringing Retrospectiveinto the Sprint Backlog
The example Team has also put a swim lane at the top for their actions or improvements that they committed to in the Sprint Retrospective. Its at the top of the picture to act as a visual reminder that continually improving their process and Team is important. Its recommended that the Developers include at least one action item from their previous Sprints Retrospective.
Adding the Sprint 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 ofUser Stories. Instead, theyre 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 its appropriate that their Sprint Backlog looks different as well.
Example Sprint Backlog 2:
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 of a Sprint Backlog
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.
Image courtesy of Sameer Bendre.
Sprint Backlog Example 3:
This Team has Expedite Lanes at the top, and column headings include Challenge, Analysis and Planning and Unit Test.
Image courtesy of David Koontz.
Sprint Backlog Example 4:
This is the Sprint Backlog of a marketing company, and theyve 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.
Image courtesy of Sameer Bendre.
Sprint Backlog Example 5:
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 thats okay. They dont have to, because a Sprint Backlog has to only make sense for the Team that created it.
More Ideas for Your Sprint Backlog
Here are other things you might try for the structure and contents of your Sprint Backlog, based on what some Scrum 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 dont 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[2] 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 teammates 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,[4] server outage, Zoom or MS Teams outage. Track mood, energy, etc using something as a simple as a spreadsheet view with peoples 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 Teams energy or focus was negatively impacted.[5]All of the information that the Team tracks via the Sprint Backlog becomes data that should be brought into theSprint Retrospective.
When your Sprint Backlog is designed and prepopulated by an outsider (or an electronic tool), its unlikely to contain any of these improvements that can help make the Backlog and what it tells you more effective and informative. But at the end of the day, if a tool helps the team improve collaboration and focus, then it is useful.
(Note, if having to maintain a tool for the Sprint Backlog slows down the Team, that is an impediment and its up to the ScrumMaster to help find a better solution.)
Sprint Backlog: End of Sprint
The Sprint Backlog is reviewed during Sprint Review at the end of the Sprint. The Sprint Backlog is finished and completed work is deployed. The Sprint Backlog cards can now be disposed. (One team I worked with archived them in a shoebox and put a rubber band around each Sprints worth. Honestly, I dont think anyone ever looked at them again.)
What happens to incomplete work in a Sprint Backlog? It is returned to the Product Backlog wherever the Product Owner deems it belongs. In the next Sprint Planning session, a new Sprint Backlog is created.
Sprint Backlog Anti-Patterns
(aka Avoid Doing These)
Pre-assignment
When the Sprint Backlog is created during Sprint Planning, some teams decide who will work on which PBI or task. When its kept to only one item, this isnt 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 cant multitask like we think we can because our brains just havent 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, theyre 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 persons 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.
Reporting
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 its not to direct the Development Teams actions it often leads to overloading the Sprint Backlog with details that undermine and eliminate transparency. The Sprint Backlog is used only by the Scrum team, and is not intended to be viewed by anyone else.
Multiple Sprints
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 shouldnt 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. Planning future Sprints before they happen reduces flexibility and increases workload for all involved.
Phases
When people come from a traditional world into Scrum, some try to use the Sprint Backlog as a tool to recreate the phases theyre used to. For example, they create columns in their Sprint Backlog for Analysis; Design; Development; Test. While strictly speaking legal, theyre 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. These phases tend to lead to another Scrum sin Staggered Sprints.
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 theyre 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 dont recommend Sprint Burndowns.
Sprint Backlog vs Kanban Wall vs Product Backlog
While the Sprint Backlog is the Teams 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 Scrums Sprint backlog and Kanbans board is that Kanban has a Work In Progess Limit. As youve already seen, I strongly recommend Scrum Teams steal a leaf from the Kanban world and do this.
Key Points on Sprint Backlogs:
Created by the Scrum Team An output of Sprint Planning Updated by the Scrum Team often during Daily Scrum Is better at progress tracking and forecasting than the Sprint Burndown Is used by team members to foster collaboration Contains whatever the team find useful often includes the Sprint Goal and Improvements Tracks impediments, blockages, interruptions, production support issues and hidden work A great data source to use for your next retrospectiveGood Scrum teams know that they own the Sprint Backlog.Greatteams experiment every few Sprints to find what they can do to make their Sprint Backlog even better.Bottom of Form
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. Youll 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.
[1] https://scrumguides.org/scrum-guide.html#sprint-backlog
[2] 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.
[3] This isnt a hard and fast rule. Instead, its 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.
[4] Github did a Developer Good Day surveyand 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.
[5] These are called Niko Niko boardsand not everyone thinks that theyre a good idea.
