A deeper understanding on…
Sprint Cancellation
Road to PSM III — Episode 11
The Scrum Guide is very reserved about the authority of a Product Owner to cancel Sprints.
“Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon.” — The Scrum Guide.
Cancelling a Sprint is a value-based decision that rests with the Product Owner and is generally called for when the Sprint Goal becomes obsolete.
A Sprint may be cancelled in the event that an organisation has to adapt to an abrupt situation. In a way it enhances agility. It generally occurs when there is something more valuable or urgent that requires the team’s commitment and focus. A Sprint doesn’t get cancelled if the Scrum Team discovers it cannot meet it. Calling for cancellations often, reveals however that focus and commitment is lacking. Perhaps even the Sprint timebox is too long for the team to timely adapt to the changing conditions in the market. It could even reveal a lack of vision, or that the Product Owner’s vision for a Sprint isn’t respected by his or hers management.
In the event of a cancellation, a Scrum Team generally gets together to plan how to adapt accordingly. The cancellation does introduce some challenges though.
What to do with the work-in-progress?
“All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.” — The Scrum Guide
The Product Backlog Items are updated to make transparent what work has been done on them. The more time passes, the less relevant this will be. Undone work introduces complexity and may result in Technical Debt. Such remaining work might still be completed if valuable, or removed if wasteful.
Sometimes a Scrum Team might consider a cancellation when they encounter showstoppers. They might discover that achieving the Sprint Goal is too complex, or that they believe they can’t finish work on time. This isn’t a valid argument to call for a Sprint to be cancelled. The goal is still valuable and the Scrum Team can still adapt the plan to what they think they can do towards it. Even it it’s just a first next step. The timebox of the Sprint is ultimately not a deadline for the Sprint Goal, only a commitment from the team to do what they reasonably can.
Another poor reason to cancel a Sprint is when a Sprint Goal is already achieved early and there is still time remaining.
The Sprint Backlog isn’t fixed and the Development Team can still pull in more Product Backlog Items or work on team improvement goals.
What to do with the work already “done”?
“When a Sprint is cancelled, any completed and “Done” Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it.” — The Scrum Guide.
The determination of wether or not items are “done” and “releasable” could be complex as there might be dependencies to “undone” work. One might argue that, if these dependencies exists, the work isn’t “done”, but there might be distinctions to how a team defines “done” versus “releasable”. In any case, this is another example of added complexities a cancellation introduces.
Another challenge a Sprint Cancellation introduces for “Done” work is how to approach their review. This is dependent on how the Scrum Team handles the Sprint Cadence.
The Sprint Cadence
“The heart of Scrum is a Sprint” — The Sprint Guide
As the heart of Scrum is a Sprint, its cadence (rhythm or routine), can be considered a heartbeat that ought to remain consistent. After all, consistency reduces complexity.
“Sprints have consistent durations throughout a development effort.” — The Scrum Guide
Cancelling a Sprint however, meddles with this consistency.
“everyone regroups in another Sprint Planning to start another Sprint” — The Scrum Guide
Sometimes Scrum Teams opt to prepone a Sprint Review and Sprint Retrospective; this effectively shortens the Sprint. Again there are complexities involved with this too. Personally I think it is best for the Scrum Team to determine what approach applies best for the situation they are in. These situations are exceptional after all.
Personally I believe that it is all the more valuable to have a Retrospective in the event of a cancellation, or at least to cover the cancellation in the Retrospective of the subsequent Sprint. A cancellation is also an opportunity for the team to inspect and adapt.
Waste
Cancellations may be considered wasteful, however, this event may prevent waste too. In any case, when cancelling Sprints, take into account that productivity, stability and predictability will decrease temporarily. It may also impact the team’s morale.
“Sprint cancellations consume resources” — The Scrum Guide
I detest the term ‘resources’ used here in the guide, but I guess I get what the guide is trying to convey.
With short Sprints (let’s say a week), it generally makes more sense to honor the cadence, even if the Sprint Goal becomes obsolete.
“Due to the short duration of Sprints, cancellation rarely makes sense.” — The Scrum Guide.
Adaptation occurs on a short cycle, which in itself limits risk. A cancellation may more trouble then it’s worth. But at times, it just doesn’t make sense to continue the Sprint for the sake of its cadence.
So Product Owner, use this power wisely.
The Road to PSM III is being reformatted to The Road to Mastery! Part I: Down the Rabbit Hole is now available.
Next episode:
