Agile welcomes changes, even when they happen late in development. The critical part is having a good understanding of the value it brings and knowing how to handle that change.
How to deal with user story changes that come in the middle of the sprint?
Agile teams focus on delivering value. For that reason, when we identify the need for a change that brings value to the customer, we should consider it even if it happens during the sprint.
However, it doesn’t mean that you should bring any kind of change in the sprint, or make it a habit.
Don’t rush it into the sprint. When a customer or the stakeholders come with such a request, the first thing I do is to analyze the requirement very well. It has to bring value and has to be aligned with everything else that’s related to the sprint goal.
Be transparent with your team. Before you make the change, give your team a heads-up and tell them about the request you are going to discuss with them. You can do this as part of the daily meeting when everyone presents their updates.
Evaluate if it’s a small or a big change. Knowing the effort it involves can help you prioritize it. Sometimes you’ll deal with urgent requests in the last days of your sprint. So you and your team have to ask yourselves if it’s worth disrupting the work in progress.
If the work you have to do is too complex, you might not complete it by the end of the sprint. And you’ll end up having unfinished work that you take with you into the next iteration.
Identify if it needs a new story or just change the current one. If you look at a major change, create a different user story that you will refine in your next refinement session. Then you can prioritize it in your product backlog.
If it’s a minor change that doesn’t affect the sprint goal, you can include it in the user story that’s in progress.
Write the additional request and the date of it if you use the current story. This is important because you can keep track of the new requirements and it gives you transparency. In case the team increases the effort they initially assigned to the user story, you will know what determined this.
Decide how to deal with it if it needs a separate story. This depends on the capacity of your team. If they agree that there is enough time to complete the new item within the same sprint, you can include it.
Otherwise, if they don’t seem to feel comfortable altering the sprint, consider prioritizing the item on the backlog. Then, work on it in one of the following sprints.
Although adding such a change at the end of the sprint, can bring with it the risk of not ending the work on time.
What should you do with changes that result from feedback during sprint review?
The main purpose of the sprint review is to receive feedback about the work that you and your team delivered. During this meeting, the stakeholders are present.
Many times, you don’t know what aspects you overlooked until you see the functionality in action. So the outcome of this meeting can be elements that are identified as missing from the initial requirement.
How should you handle these changes? Do you create a new user story, or do you reopen the one you have previously marked as done?
A user story is complete when it meets the definition of done. Which should include you ticking off the acceptance criteria that you and the team agreed on. So once you mark the user story as done, you should not reopen it.
The best way to approach this is to create a new user story, then refine it and prioritize it on your backlog.
If it’s a valuable change from a business perspective, place it on top of the backlog. Then, you can assess if you want to include it right in the next sprint or if you should wait.
If the sprint starts the day after the sprint review, you can use the time you have to discuss the story with the team and identify before planning if there is any more information they need.
If you cannot get the information soon enough, you can negotiate with the team and leave a buffer to include the story later in the sprint. However, the best approach would be to wait until the next sprint starts.
What are the downsides of modifying user stories during the sprint?
You may create dependencies. Any change to a user story can bring with it dependencies if not handled correctly. If you include it in a sprint, make sure that it will not affect a future user story or the next sprint.
If the additional request is stopping the current item from being completed by the end of the sprint, you should seriously consider not accepting it at that moment.
It can become a habit. You should be open to accepting changes during the sprint. But this should not become a habit because it is not a healthy approach in the long term.
It can create an expectation with stakeholders that anytime they have an additional request, it’s normal to interrupt the sprint.
It can affect the team’s velocity. The plan you make for the sprint when it starts, it’s also based on the velocity of your team. But when additional work comes in, it affects the normal flow first.
You have additional discussions, and you also might need to re-estimate the user story if you bring modifications to it. This might lead to extra hours worked that can affect the reality of future sprints.
You look unpredictable as a Product Owner. When you constantly change requests within the sprint, you don’t seem to have a reliable plan. Mistrust will build up in your team and it will affect the relationship between you and them.
Conclusions
Even if you allow changes into the sprint, you have to be careful what those changes are and how you handle them.
Try as much as possible to find alternatives to avoid this to happen, even if it means negotiating with the stakeholders or customers. However, when it’s not possible, make sure you are transparent with your team. And, that everyone is involved in the decision-making discussion.