Replacing Items when the Sprint has Already Started

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?

Ok, but still, Scrum says that we should not do it! Really, where and when did the Scrum say 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. 3.Really, where and when did the Scrum say that? Scrum guide is actually pretty silent on this topic. Except for saying thatand that. 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.