One of the most common issues that arises with a Scrum Team is that the content of a Sprint needs to change during the Sprint. This happens for a number of reasons, and this excerpt from Exploring Scrum: The Fundamentals will touch on one reason this may occur: The team can’t do what it agreed to.
This is one of the more painful situations we have in Scrum. What if the Team just can’t finish what it agreed to do? This situation may make the Team Members feel badly 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. So, 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 Stories, or 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. I 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 to just 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, I know it is painful, but this is Scrum, not the playground.
Change Done Criteria
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 (taking shortcuts and increasing Technical Debt) is the least palatable, as it involves relaxing the Definition of Done and purposefully creating Technical Debt. The Team may need to do this because it really needs to deliver all the Stories, and 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 nonetheless…). This decision can’t be made lightly, and 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.
I 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 (and they go in the Back Burner so that they are always visible – right in everybody’s face – they 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 the system, 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 done so, and that they agree it’s the best, if not only, way to go.
This is an excerpt from Exploring Scrum: The Fundamentals. For even more practical knowledge on changing your sprint’s plans (for a lot of different reasons) you can purchase Dan Rawsthorne and Doug Shimp’s book “Exploring Scrum: The Fundamentals” on Amazon. Stay in touch with 3Back on Facebook and Twitter.