There’s an ongoing discussion in the Scrum community whether you should you replace a sprint backlog item with a product
backlog item of equal size, when the sprint has already started. What inspired me to write this blog post is
that I have have heard some Scrum Masters dogmatically preaching that sprint backlog items should remain locked
down in that situation, no matter what.
Their arguments ranged from: “It will downgrade teams level of motivation” to “What is the point of Sprint then? That is
against the rules!”. While there certainly are some downsides, wearing a Scrum Master hat requires being pragmatic,
as well as knowing when you should negotiate and when you should not.
Here are the reasons why you should replace items when the Sprint has already started if the business requires it:
1. It is the business which enables the product to strive and survive, not the development process. Sometimes, you have to
intervene right away for the business itself to keep going. Just think of any banking software – a severe bug
in a production environment might cause so much damage that it could ruin the bank. Would you have the luxury
of being dogmatic about your development process then?
2. Ok, not all of us are in the banking business. Some of us are developing Social Networks for pets, and can tolerate bugs
in a production environment for a few weeks. So, no need to ever replace a Sprint backlog item, right? Well, no.
What if the business priorities change and some features from the product backlog become way more important than some features
in the Sprint backlog?
Agile Manifesto says “Responding to change over following a plan". So, if the plan is not reflecting business priorities anymore,
why should you follow it?
3.
Ok, but still, Scrum says that we should not do it! Really, where and when did the Scrum say that?
Scrum guide is
actually pretty silent on this topic. Except for saying that
during the Sprint no changes are made that would endanger the Sprint Goal and that
scope may be clarified and re-negotiated between the product owner and the development team as more is learned.
Although some influential people in the Scrum community strongly suggest that you should not replace Sprint backlog
items when the Sprint has started, this is not what Scrum guide claims.
In reality, sprint goals can change. The scope can be modified both because of the business needs and because of the bad development
insights. However, a Sprint where you have replaced a Sprint backlog item with some other product backlog item
can still be a successful Sprint, provided that you have delivered the needed value.
4. In the end, are there any other options? If the product backlog item is really more important than the whole Sprint goal,
the only other option from the Scrum guide is for the product owner to cancel the sprint and start a new one.
Although this is allowed by the Scrum guide, the effects of it can be tremendously devastating for the development
team’s motivation, way more than just replacing a Sprint backlog item.
Now, I am not saying that you should be doing this every single time someone requests it. Scrum Master should educate the
product owner about the downsides of doing this often, and the product owner should carefully decide whether
the issue can wait for the next Sprint. As for the development team, it is up to the Scrum Master to coach them
about how the business works.
The final question is where the limit is? Well, if this is happening on a regular basis, it probably means that you are in
a
Chaotic environment.
If you identify with this environment, you might want to reconsider whether the Scrum is the best framework for
you to use and go with
Kanban instead.
Thanks for reading, and if you have any comments or questions, feel free to hit me up on
Twitter or
Linkedin.