Do you find it difficult to decide whether you should remove stories from your sprint? Maybe you’re worried about how your team might react. If you are a Product Owner, I’m sure you’ve been through that.
The trick is to know why you should consider it and how to make this decision. Removing stories from the sprint is not always a bad thing. Sometimes this will bring more benefits to the delivered value than working on something you don’t see as valuable anymore.
Why you should be flexible about removing user stories from the current sprint?
- You maintain a good relationship with your customers
Customers report bugs all the time. Before deciding to replace something in your sprint to fix a bug, make a quick analysis. You’ll find out who is the client, how the bug affects his business, and if the same happens to other clients.
Such analysis will help you understand the criticality of the bug and decide what you do next.
This type of situation requires sometimes putting aside a story you planned for the sprint. Your other option would be to include the bug in the next sprint.
However, if delaying to solve an issue can create more problems than not implementing a feature, you should not hesitate to swap those work items.
2. You’re confident your team invests their time in a valuable outcome
Many times, developers can identify missing steps while developing features. This means that you may need to create a new user story.
It happens when an intermediary step of the flow is overseen in refinement or in the discovery phase.
If it has to be included instead of something else that you planned for that iteration, you should not be worried you have to change the plans during the sprint.
3. You don’t waste time with something that you won’t release for the customers
If a work item becomes obsolete during the current sprint, waste no more time with it.
For every story in your sprint, you have invested time to create it, estimate it, and plan it. So you may think that if you discard the item, you will lose all that invested effort. You may also think that it’s better to complete the story, just in case you will need the code in the future.
Continuing to work on an item that you won’t release, only because of the time invested, makes you miss the chance to deliver something meaningful.
When you shouldn’t alter the sprint?
Different situations require different approaches. If there are cases when pulling out stories is preferable, there are others when you shouldn’t. Here is when.
- The team realizes there’s too much work in the sprint
Often, teams take much more work than they can complete within the iteration. And they realize this late in the sprint.
Overcommitment and poor experience with estimations can lead to that. And this is a great improvement opportunity that you can discuss in your retrospectives.
But if you remove the stories that cannot be completed, you may lose the chance to see the pattern and understand what happens.
Workshops and agile coaching are excellent ideas to help your team. There are many estimations techniques that a Scrum Master can present to the team. And work together with them for a better understanding of how much they can deliver.
2. You’re only half a user story away from the perfect burndown chart
Metrics have one purpose: to help us see what we are not doing well. Realizing what we do wrong is difficult without tracking our activity and generating data we can analyze later.
Once we see the pattern, it’s easier to understand what we have to improve, and start finding out how.
But when we move around stories in and out of the sprint, to make our charts look good, we lose the opportunity to improve ourselves.
So removing a user story from the current sprint, only because it wasn’t ready, is not the best decision you can make for your future effectiveness.
3. You discover more scope
Refinement sessions have a key role for your sprint to stay untroubled. They allow you and your team to get together and discover any missing piece of the feature you want to implement.
Good refinement sessions are the ones where everyone is active, asks questions, things get clarified, and impediments are discovered.
Many times, a lack of activity or disinterest in refinements will lead to more scope being discovered during the sprint.
This is when you get panicked and pull out stories from the sprint.
However, the best approach is to leave the sprint as it is, and in the next retrospective, talk about ways you can be more active in refinements.
What should be your ground rules before removing stories from the current sprint?
- Re-negotiate the sprint goal with the team and decide together when you can pull out a story, and why you do it. Don’t make this decision by yourself, otherwise, you’ll hurt the relationship you have with your team.
- Inform stakeholders of the changes you are about to do. You don’t want them to be surprised they didn’t get what they expected initially. Transparency has to exist at all levels in Scrum.
- Understand how this will affect velocity and future forecasts. Switching focus involves delays as well. So you want to be aware of the size of the change you are bringing in, and at what moment of the sprint when this is happening.
- You will not make it a habit. Although sometimes you must do it, don’t let it become a day-by-day practice.
Conclusions
Removing stories from the current sprint can both affect and be in your team’s favor. You shouldn’t remove or replace user stories without making sure that it brings more benefits than damage.
A good analysis of the situation you find yourself in will offer you the information you need to know what is best for the customer and for the team.
Otherwise, this will become the norm and you’ll drift away from Scrum best practices.
