A deeper understanding on…
The Sprint Backlog
Road to PSM III — Episode 15
The Sprint Backlog:
- is a forecast containing a set of Product Backlog items selected for the Sprint,
- a plan for delivering the product Increment and realising the Sprint Goal,
- and contains at least one high priority process improvement (from the retrospective).
Check, check, check?
Fixed or not?
The Sprint Backlog emerges.
“This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.” — The Scrum Guide.
So indeed no, the Sprint Backlog is not fixed. Neither are the forecasted Product Backlog items. It is what the Development Teams believes it can do for the Sprint which changes as more is learned during the Sprint. The team continuously determines what is can do best towards achieving a Sprint Goal.
Push or Pull?
So who determines what goes into the Sprint Backlog? I’ve engaged with several Product Owners who argued that they should be the sole person to determine what goes into the Sprint Backlog and in what order the items should be worked on. Some Product Owners believe that only they can make changes to it as they argue that they are, as the Scrum Guide states “responsible for maximising value” and that “the entire organization must respect his or her decisions”.
Although the Scrum Guide does indeed mention this, this is referring to the Product Backlog. Not the Sprint Backlog. Big difference. As a Product Owner, you don’t own both. Scrum is pull!
Really it is.
The forecasted number of items is determined by the Development Team:
“The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team.” — The Scrum Guide
Now one might argue that indeed this only determines “the number of items”, not what those items should be. So to be clear, the guide also mentions:
“The Development Team works to forecast the functionality that will be developed during the Sprint.” — The Scrum Guide
However… [oh boy]
During the Sprint Planning (where the work for the Sprint is forecasted):
“The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal.” — The Scrum Guide
Now I highlighted both ‘discusses’ and ‘objective’. ‘Discussing’ isn’t ‘deciding’. Neither is the objective the same as the Sprint Goal.
A Scrum Team could discuss various objectives, or discuss exactly how it defines an objective (you could too say ‘goals’). Once agreed and a shared understanding is developed, it becomes the Sprint Goal.
[edit for clarification:]
They can indeed discuss various possible or potential objectives, and either select, refine or construct one that defines a common purpose. This provides guidance to the Development Team on why it is building the Increment. The whole team can focus(!) on this single purpose, which becomes the Sprint Goal. — I’ll refer you to this article at Scrum.org on what makes a *good* Sprint Goal. It covers the challenge of working on unrelated initiatives.
Let me emphasize that though the Product Owner does indeed discuss the objective and potential Product Backlog items for a Sprint, the Product Owner doesn’t decide but may influence. Hence,
“This plan is created by the collaborative work of the entire Scrum Team.” — The Scrum Guide
The same goes for crafting the Sprint Goal, this too is a collaborative effort. So, just so we are all on the same page: though the entire Scrum Team, including the Product Owner, collaborate… it’s the Development Team that decides.
“Only the Development Team can assess what it can accomplish over the upcoming Sprint.” — The Scrum Guide
For those still not convinced…
“The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.” — The Scrum Guide [emphasis added].
What about making changes during the Sprint?
“The Development Team modifies the Sprint Backlog throughout the Sprint” — The Scrum Guide
Clear.
“Only the Development Team can change its Sprint Backlog during a Sprint.” — The Scrum Guide
Even clearer.
If changes are needed, more can be pulled in by the Development Team often supported by the Product Owner. And,
“As new work is required, the Development Team adds it to the Sprint Backlog.” — The Scrum Guide
How about removing work? Surely the Development Team can’t just remove work right?…. wrong.
“When elements of the plan are deemed unnecessary, they are removed.” — The Scrum Guide
I know this indeed scares the bejeebers out of traditional PMs.
But here it the clause everyone can agree on:
“No changes are made that would endanger the Sprint Goal;” — The Scrum Guide
Why?
But I am not writing this series just to explain what the Scrum Guide has to say, but as an exercise to discovering why the Scrum guide says what it says. In the episode about the Scrum Team and Development Team we covered why (and how) Scrum promotes self-organization of the work.
It is indeed the Product Owner’s role to order the Product Backlog in such a way it becomes transparent what the Development Team should focus on. The Development Team will learn why it is doing what it should be doing. It discovers its purpose. This motivates individuals to work together as a team to fulfill that purpose. When they are trusted and given the right environment and means, they can take ownership and accept responsibility.
“Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.” — The Agile Manifesto.
Let me put it this way… if a team is prescribed/dictated a goal, or worse, only a subset of tasks, to which it doesn’t understand the purpose, nor understand to whom it is valuable, it will not be able to creatively and productively construct the best approaches. It will have a hard time detecting and dealing with impediments. What’s more, as there is no consensus to it being at all feasible, or even properly understood, they will not, rightly so, feel responsible for it. They might still do their very best… but the game is likely lost before it kicked off.
A motivated, creative, adaptable Development Team is what makes Scrum so powerful. But they do need to be empowered. That starts with trust.
Another reason why the Development Team self-organizes their work, including the order in which the work is done, is because what is most valuable might not be developed first. So in a way, one could say, it prevents the cart being put in front of the horse. The Development Team may resolve dependencies first, or choose to test their riskiest assumptions first.
Make Work Visible!
“Scrum Board: a physical board to visualize information for and by the Scrum Team, often used to manage Sprint Backlog. Scrum boards are an optional implementation within Scrum to make information visible.” — Scrum.org Glossary
When most envision a Scrum Team, they envision a team standing in front of an organized board, visualizing a process flow, orderly stacked with post-its.
A Scrum Board is however not part of the Scrum Framework itself.
“The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal.” — The Scrum Guide
This is once more emphasized:
“The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint” — The Scrum Guide
How the Scrum Team goes about this, is up to the team to self-organize. They continuously improve the way they do this. Many visualize this on a board, and thus call it a Scrum Board. Often, teams are prescribed the way their process flow is organized, for example by some over-enthusiastic Jira admin.
This violation I addressed here:
The Development Team manages this board, including its flow. It most certainly is not the job of a Scrum Master to keep this board up to date or act as a police officer to make sure everyone keeps it up to date. A Scrum Master can however make transparent what the impact is of not having an up-to-date real-time visual picture or assist the teams by sharing techniques and encouraging them to improve.
Scrum Board, Kanban board?
Many Scrum Teams, knowingly or not, visualize progress using Kanban techniques.
Scrum doesn’t prescribe how a team is to design its processes. Scrum does encourage teams to self-organize and improve its processes routinely, and to make it visual. Now Kanban is a strategy for visualizing and optimizing the flow of stakeholder value through a process. 🙌
Seriously, if anyone is interested in learning about techniques on how to visualize and manage the Sprint Backlog, check out the official Kanban Guide for Scrum Teams!
Flow
Some will argue Scrum doesn’t enable continuous flow like Kanban. Even big institutes, yeah even the one creating the dreaded Software most of use, like Atlassian, get this dead wrong.
“Teams should strive to not make changes to the sprint forecast during the sprint.” — Atlassian on Kanban vs Scrum
This statement, like many in this article, is a misinterpretation. I will not address all of them here. Scrum most certainly is all about continuous flow.
As we have already established, the Sprint’s time-box isn’t a deadline, neither does the work to a PBI have to be strictly limited to a single Scrum Sprint. All this, so as to enable flexibility as well as creative and intelligent decision making within the Development Team, towards planning and delivering the Sprint Goal.
I’ve worked with Scrum Teams who only defined the work for first days of the Sprint and they pulled in more as the Sprint progressed. This included new Product Backlog items into its forecast. Scrum Teams work out whatever flow works best for them. A Sprint Backlog doesn’t have to be full at the start or empty at the end of a Sprint. Work that isn’t “Done” will simply not be part of the Increment and may (or may not) be continued in the next Sprint.
How to monitor progress towards the Sprint Goal?
“The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal.” — The Scrum Guide
How Development Teams go about this is, again, up to them. The visualization of progress benefits transparency, inspection, and adaptation. Significant aspects of the process must be visible to those responsible for the outcome. If this isn’t visible or transparent, teams will not be able to make timely decisions and perform timely adaptations. Decision making will be poor and will incur waste. Routinely inspecting progress on a daily basis and (re-)aligning on how to proceed (flexibility and adaptability) is one of the key strengths of a Scrum Team. The values of commitment, courage, focus, openness, and respect should really be demonstrated here.
“The Scrum Team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members respect each other to be capable, independent people.” — The Scrum Guide [emphasis added]
Though some teams choose to work with a Sprint Burn Down Chart, showing a trend in outstanding work during a Sprint. The Scrum Guide does emphasize that inspection is best done by inspecting actual progress of actual work done, rather than inspecting a chart.
Impediments
A Scrum Team should detect and timely deal with potential quality issues. These shouldn’t be ignored/postponed.
“We want to know about impediments before they become blockers. If a team is good at highlighting impediments, it means that they are anticipating issues in quality, and preventing blocking issues in productivity downstream.” —Andon processes by Paddy Corry.
The Sprint Backlog can visualize (potential) impediments or quality deficits. So if we take any learnings from the Toyota Production System to heart… this visualization could act as its Andon cords so teams can treat is before it leads to further waste and technical debt.
Scrum Teams can learn to become aware of issues at the earliest possible moment. This instant (re-)alignment enables them to resolve detected quality deficit instantly before waste and debt incur. Enabling this is highly efficient. The way this is visualized on the Sprint Backlog can contribute significantly to this.
Detail
To what level of detail should Sprint Backlog items be defined?
What we can learn from updates to the Scrum Guide is that, originally, all the work was made visible in the Sprint Backlog. This included all the work related to each and every Product Backlog item, no matter how small those items and related tasks might be. Though some might enjoy the idea of micro-level tracking of tasks, this introduces waste too, and can be dangerously demotivating.
In the article The New, New Sprint Backlog by David Star & Ryan Cromwell, they covered why certain changes were made to the 2011 Scrum Guide, and one reason was to counter this. Hence the Guide now reads: “all the work that the Development Team identifies as necessary to meet the Sprint Goal”-SG. So this clause leaves it up to the Development Team to determine what it identifies as necessary in relation to the Sprint Goal, not necessarily each and every single PBI it works on.
There are many awesome tools and techniques for Sprint Backlog management, personally I think the Kanban Guide for Scrum Teams should be anyone’s first stop.
Looking for more ammunition to bust the myth that a Sprint Backlog is fixed? Check out this article by Christiaan Verwijs:
Thanks Paddy Corry for sharing your thoughts and reviewing this episode.
The Road to PSM III is being reformatted to The Road to Mastery!
Part I: Down the Rabbit Hole is now available.
Continue:
