If you have read the 2020 Scrum Guide, most people notice that it has shrunk from 19 pages in 2017 to 14 pages in 2020. The Sprint Backlog section is one of those that has been reduced. I believe this was to make room for the Sprint Goal.
Scrum Guide 2017
“The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment. The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting. The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal. As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. 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.”
Monitoring Sprint Progress
“At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.”
Scrum Guide 2020
“The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how). 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. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.”
Commitment: Sprint Goal
“The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives. The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.”
– All in all I think these say much of the same thing. The “Monitoring Sprint Progress” has been removed as to make room for a new section specific to the Sprint Goal.
What is key here is Scrum is purposefully once again calling out a “single objective”. And then further adds to this with this statement;
“The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.”
A common thing I have experienced with Scrum over the years is with teams utilizing the Scrum Framework but still working on their own individual items. Time and time again this is due to managements focus on things like “resource allocation”. Which is a fallacy that more things in progress, with more people, create more things faster. This is patently false, especially when it comes to knowledge work such as software development. Now I am not saying, and neither is Scrum, that you must pair or mob/ensemble program. What is being stated is that if you have multiple objectives in a single Sprint with multiple Sprint Goals with everyone working towards their own objective and goal, then you do not have a team working together to achieve anything.
Another good thing that is being called out in here is the ability to adjust scope in collaboration with the Product Owner to allow for reaching the Sprint Goal. Since this is Scrum we point to that collaboration with the Product Owner, but very many highly effective and successful teams in very highly effective and successful organizations work directly with their users to achieve this goal.
Bottom line here is the days of having the items in the Sprint locked in the same state as they entered is over and has been for a long time. This is not just the items themselves, but the work within the items is able to shift and change to better suite the Sprint Goal.
This quote, which I can’t seem to find in any Scrum Guide but is in a “Scrum Master Training Manual” seems to be the cause of most of the heartache when it comes to the Sprint Backlog.
“In Scrum, all requirements related to an ongoing Sprint are frozen during the Sprint. No change is introduced until the Sprint ends, unless a change is deemed to be significant enough to stop the Sprint. In the case of an urgent change, the Sprint is terminated and the team meets to plan a new Sprint. This is how Scrum accepts changes without creating the problem of changing release dates.”
This is completely false in every possible way and goes completely against working in any sort of agile way at all. Think about it, what if we are in mid build of something and realize what we are doing may not be worth doing, or even the crazy scenario where we ask our user, or Product Owner when using Scrum, to take a look at something being built to make sure we are on the right path, and they say “oh no, now that I see it, this needs to change.” Do we say “too bad, sorry, no take backs, the Sprint is frozen, we will build it as the original requirements stated, and change it in the next Sprint.” …
The Sprint Backlog is a flexible set of items specifically targeted towards achieving the Sprint Goal. If removing Sprint Backlog items during the Sprint still allows us to achieve the Sprint Goal, that is a great thing, that means we didn’t really need that thing. If changing some of the details of an Item in the Sprint allows us to better achieve the Sprint Goal and doesn’t put the Sprint in danger, then great, do it. If it does however put the Sprint Goal in danger, then it would be something we would do in the next iteration. I have yet to experience the instance when doing less with still being able to achieve the Sprint Goal causes undue burden on a team.
Standard line here 🙂 If anyone wants to share some feedback or discuss anything about the Sprint Backlog and the Sprint Goal, I welcome that.
Chris Pipito 