Our Sprint wasn’t cancelled (but my trust in Scrum was)
Why you should cancel a Sprint and what happens when you don’t
I’m not here to point fingers. No one could foresee that our sprint goal would go completely obsolete, and it’s easy to understand a manager who feels like cancelling a sprint is like admitting failure, but things shouldn’t be that way:
A Sprint is just a time-boxed container for Scrum events; arbitrary and independent from the people and work in it.
When a sprint is cancelled due to obsolescence (the only factor prescribed by the Scrum Guide itself), we don’t set computers on fire nor do we delete the useful stuff in the Sprint. We also don’t exchange blame and crucify managers; we simply review useful tasks and start a retro to understand why our squad has been building useless stuff so we can prevent it in the future.
Otherwise, what you get is 2 unexpected holidays for not having the courage to face a Retro and a new Planning. You’ll end up with managers foraging the backlog to pick whatever can fit in the sprint — and devs will greet you in the following morning with “hahaha, I don’t even know if that can be built!” (Meaning more hours lost in wait for the tech lead, which would confirm the disgraceful news.)
A frustrated team; an obsolete goal; another sprint with no value delivered. Pardon me, but here’s something that should be made clear to all agile teams:
Agile is 100% NOT about quick task completion, but quick value delivery. Agile brands seek ROI, not clean backlogs.
Scrum is an empirical process: you analyse what works and what doesn’t to draw your conclusions and make you next sprint better than the last.
Scrum is also about delivering value better and quicker after learning from retros: if your goal has gone obsolete and the squad is now working on random tasks just to finish the sprint, what you’ll get is a beautiful “Done” column at your end and a miserable customer at the other end.
No, I’m not suggesting every sprint should be cancelled when there’s a slight issue with your goal — adaptation is one of our pillars, after all — but if it came to the point that your Sprint Goal rendered your Sprint Backlog pointless, why not start a Planning instead of wasting two hours discussing blame and picking random tasks from Product Backlog just for the sake of completion? (And a bit of pride, of course.)
“Sprint cancellation is a value-based decision” — S. Nijland
We are not being transparent if we aren’t willing to face failure, meaning we won’t inspect what went wrong nor will we learn to adapt processes and plans to avoid this sort of debacle. In conclusion, tasks will keep dashing to the Done column whereas Value will take a backseat in the backlog.
Maybe we should print our burndown charts and put them on sale instead?
Suspecting that my colleagues would try their hardest to forget failure before the sprint ended, I coaxed everyone into a semi-retro which revealed our biggest problem was not having clear objectives.
The commercial tribe was going through corona chaos and suggesting all sorts of solutions while keeping longterm objectives for themselves — inducing us to help them extinguish the fire while also leaving our OKRs in second place, thus making it easier for nonsensical requests to pass.
A wild wasterfall appeared. It stealthly leaked tasks from others managers to us, fully unnoticed before drowning us.
That’s when we agreed that objectives should be visible to all 24/7 so now we can clog those cascades more easily. There was just one problem: how would we ensure everybody would follow objectives now that we no longer have a shared wall to hang our goals?
Let’s be honest: no matter how easy it is, no one wants to open any page to search for something abstract and boring such as OKRs — but luckily no one will have to, because I stumbled upon Maarten’s guide on Roadmap Epics!
Turning OKRs into Epics made it all conspicuous to both squads and also brought the roadmap just one click away from every manager as objectives and key results are now following us in the sprint board every day.
A new task leaked? They now have to show us how it fits our OKRs since the Epic/OKR field is required — and if doesn’t, no problem: there’s a waterfall epic for that, so we have an easier time prioritising what matters and detailed stats to show stakeholders / upper managers where resources were wasted.
No, we didn’t cancel the Sprint as I pleaded but we’ve discussed and discarded so much that the result was the same (unofficial victory!), paving a new way to this squad that can no longer run a sprint just for its sake.
“Sprint cancellations are often traumatic”, the Scrum Guide states, but I posit that the worst trauma your squad can have is to feel useless day after day.
Special thanks to Maarten Dalmijn for taking the time to review this article with his insightful feedback. As an avid follower, it’s a huge honour.
Do you want to write for Serious Scrum or seriously discuss Scrum?
