The blog post read: “For my teams, as they cannot fully shield themselves from changes in a Sprint, the 20% reserve allows them to [adapt]/deal with most changes, and keep their Sprint commitments.” The team was breaking work down into hours, then keeping a “slush fund” of spare hours to cover unexpected additions to the sprint.
This didn’t sound right.
Let’s remind ourselves about the basics. The following are taken from scrum.org’s The Scrum Guide (highlighting is my own):
“After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.”
“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.”
”If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.”
“When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint.”
“No changes are made that would endanger the Sprint Goal.“
Of course, should the Sprint Goal no longer be relevant then the PO has the option to pull the plug: “A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. … But, due to the short duration of Sprints, cancellation rarely makes sense.”
So with the above in mind, re-read the initial except from the blog. A big question is ‘Where are the changes coming from?’. If they’re emerging as the team works through the backlog and learns more about the work needed to achieve the Sprint Goal, then it’s not so bad (although I’d still question whether capacity planning in hours is the wisest move). However, if the changes are coming from the PO or business, then a re-read of The Scrum Guide and a press of the restart button might be best.
Image courtesy of brokerx (Pixabay)