Having a Team that just can’t finish what it agreed to do in a Sprint is, by far, one of the more painful situations we have in Scrum. This situation may make the Team Members feel bad about themselves, and they may want to do these Stories no matter what…
Since the Team actually agreed to the Stories’ Doneness Agreements, this means that they can’t meet all the Agreements that they agreed to do. There are only two basic things the Team can do: remove some Stories or modify some Agreements. The second case actually has two options: the Team can split a Story and remove part of it, or it can decrease quality and produce Technical Debt. So, there are three options in total:
- Remove Stories
- Split a Story and Remove Part of It
- Increase Technical Debt.
Before discussing these options, we must all remember that the Team’s agreement to the Stories is an agreement between the Product Owner and the rest of the Team.
The best of the three options is to remove Stories from the Sprint. We believe that it should be possible to remove (at least some) Stories without affecting the Team’s achieving the Sprint Goal. Remember that the reason there is a Sprint Goal defining the Sprint’s success is so that the Team has the wiggle room it needs to allow it to fail to do some of the Stories. So, the preferable option is just to remove whatever Stories are necessary, while still achieving the Sprint Goal.
Luckily, the Stories that the Team hasn’t started yet are probably the least important ones in the Sprint – they aren’t needed to achieve the Sprint Goal – and can easily be pushed into the next Sprint. This will have an effect on the Team’s Velocity for this Sprint, and that’s a shame, but it’s the reality we’re dealing with. And yes, we know it is painful, but this is Scrum, not the playground.
Split a Story and Remove Part of It
The second best thing to do is to split a Story and remove part of it. This can only be done if we have a large, decomposable Story that can be split. Generally speaking, we don’t want to have Stories like this in our Sprint in the first place; but if we do, we could split one of them into two Stories and then remove one of them. This is not easy, but it can sometimes be done. The things we need to worry about when we split the Story are that each of the sub-Stories still has a Doneness Agreement that mitigates Technical Debt and that each Story still has enough Stakeholder value that it can elicit meaningful feedback.
Increase Technical Debt
The third case (involves taking shortcuts and increasing Technical Debt) is the least palatable, as it involves relaxing the Standard of Care and purposefully creating Technical Debt. The Team may need to do this because it really needs to deliver all the Stories. This must mean that the cost of not delivering them in this Sprint is higher than the future cost of the Technical Debt created. (This shouldn’t happen, but it does nevertheless.) This decision can’t be made lightly. It is a decision that is owned by the Product Owner but should probably be agreed to by the Business Owner, as well as other Stakeholders.
We hate this option! But some Teams think it’s a good idea. If your Team is one of those Teams, just remember to add Cleanup Stories to the Backlog. (The Cleanup Stories go in the Back Burner so that they are always visible – right in everybody’s face – and will never slip to the Fridge.) Make sure that it is visible and well known that the Team created Technical Debt, and that the Team has promised via the Cleanup Stories, that they will fix it. Additionally, make sure that all the Stakeholders (or at least the Business Owner) know that the Team has created Technical Debt and that they agree it’s the best, if not only, way to go.
Looking for more tips on how to successfully adjust a Sprint’s content?
We’ve got a great book for that.
As Always, Stay Agile.