We start every sprint of a typical project the same way. We commit to completing a set of work. This is done only after we have sufficiently planned out the work, identified all dependencies, and are confident in our sprint plan. We take our commitments seriously, as should be expected. It’s a promise that we are making to our customers. Ideally no team wants to make changes to a sprint after a commitment has been made, but the reality is that it happens. The downside of making a change to a sprint after it has started is that it comes with a cost. Not only does it impact the team’s progress and velocity, but it inevitably causes some other previously committed work item to slip. It’s important to provide the Product Owner with the necessary details so they can make an informed decision about whether the cost of impacting the team is worth the benefit of getting an item delivered sooner.
When dealing with potential mid-sprint changes, ultimately the decision is to either accept the change within the sprint or hold off and plan the work in a future sprint. Our process for handling change within a sprint starts with identifying the amount of work required to complete the additional ask. We plan out the remaining days of the sprint as if we are committing to accept that change (note, there is work required to conduct this additional planning exercise and should be taken into account when determining impacts). This planning exercise helps identify what the impact of that change would be. We provide the updated plan to our Product Owner and let them make an informed decision. Do we allow the new work item to be added to the sprint knowing the potential impacts, or does it get added to the backlog in a future sprint?
I like to use an analogy comparing committed work in a sprint to that of a glass of water. If you have a glass full of water, adding ice to the glass will cause water to spill out. The same concept applies to sprints. If a user story or bug is added to a fully committed sprint, then that means some other user story or bug must be moved out. This isn’t always a one for one swap. As I mentioned, it took additional time to understand the new work item. It required effort to plan the necessary work to deliver it. It caused team members to stop what they were working on, and shift focus to something different. These impacts are in addition to the work required to deliver the new work item, and they should not be overlooked.
Sprint commitments are a big deal here at Clientek. Changing a sprint after it has been committed to causes impacts. Sometimes those impacts are worth it, sometimes they are not. It is our responsibility to make sure that our Product Owners understand the full impact of making changes, so they can make informed decisions.