Although breaking down user stories is one of the important skills of an Agile team, we struggle often to split those working items into smaller pieces.
Even if not all user stories will fit under the same approach, there are a few common mistakes that we all do with all of our user stories. Let’s see what they are.
1. Product Owners and Developers don’t collaborate
User story splitting is not only the Product Owner’s responsibility. The entire team should get involved in this activity.
Many times, you, as a Product Owner, are breaking down working items by yourself. And as many times, you create dependencies because you are not always aware of the technical details in the working area.
You can easily block other items when you break them down by yourself. And it happens so often to find out about the dependencies during the Planning session.
Why you should collaborate with the team:
- Developers can identify ways of implementing the work efficiently
You may split an item into five others, which make sense from a business perspective. But from a technical one, it can make the job two or three times more difficult, so the team will deliver the work later than expected.
Undoubtedly, the Product Owner takes the final decision. But it’s better to be aware of all details than not knowing some issues you could avoid.
What I always recommend to Product Owners is to trust their teams. Development teams shouldn’t just execute a plan. They should be part of the decisions you make as a group.
- The team can help you identify gaps between user stories
You can easily leave aside details while splitting user stories. But looking at things from a different perspective can help you identify missing pieces.
This is where the developers and testers you work with can bring in their knowledge about the product. They have the information to help you make the connections between stories, to get a seamless flow.
They know very well the product and can identify many scenarios. Being the Product Owner doesn’t mean you are the only one who knows the product.
You are working within a team and everyone is welcome to bring in ideas and vision.
- Considering testing scenarios can help testers perform their tests in a more logical way
When there are multiple elements to be implemented in the same area, it’s easier for testers to test all the functionality in the same area at once. And sometimes, splitting the item in the wrong way only slows them down.
Your goal for each sprint should be clearly stated, but how the team is going to meet the goal is their decision.
If you have never done this, here is how you can approach the topic:
- Ask the Scrum Master to organize a workshop where the entire team can learn about existing splitting techniques
- As an exercise, take some of the working items on the backlog and split them based on the techniques you present
- Apply the techniques in each Refinement session while there are user stories to split
2. You split user stories too early
One downside of splitting user stories too early is that you might not need that piece of work by the time the team is supposed to begin development. For me, what worked well, was breaking down only the items that the team had to work on in the following sprint.
In one iteration, there is a lot you can observe from what a team develops. And you might realize that some stories are not relevant anymore.
You’re splitting user stories too early if
- You drop many stories throughout the implementation
- Based on your team’s velocity, you split for more than 2 sprints of work
How can you approach story spitting to have just enough work for your team?
- Present to the team the user stories you created, and don’t get to the smaller version of it by yourself
- Ask the team to estimate the user story if they feel they have enough details
- At this point, you might be in a position where you have to decide if it’s worth investing time into that piece of work. You might decide this by yourself, or check with other stakeholders
- If you decide you should continue, in the same Refinement session, start splitting the stories together with the team. If you need to have a discussion with other stakeholders, you might have to wait for the next Refinement session
3. There is no value delivered at the end of the sprint
A good user story splitting implies having a deliverable at the end of the sprint. But what does a valuable deliverable mean?
It’s about a piece of work, that even if not released in production, when completed, anyone who sees the end result can understand what that small functionality does. If only the development team can test it by running some scripts, it’s not enough.
However, there can be exceptions where this will happen, but as a good practice, most of your user stories should respect the INVEST and vertical slicing principles. Here is a great article where you can read more about INVEST.
Why should each user story deliver value on its own?
- To avoid creating dependencies between user stories
- When dependencies appear, it’s more difficult to plan the sprint
- You might end up carrying the user story with you for several sprints
4. Applying the horizontal technique instead of the vertical slicing principle
Look at this slice of cake. Would you eat the layers one by one, or have a slice that combines the taste of all layers?
The same applies to user stories.
If you create user stories that build the layers one by one (DB, middle tier, UI), you’ll end up having pieces of functionality that cannot be showed at the end of a sprint.
But when we split user stories into vertical slices, there will be a small part of that functionality that can be demonstrated, or even delivered.
There are, however, cases when it’s better to use the horizontal technique. But a best practice is to split user stories based on the vertical principle as much as possible.
5. You create too many unnecessary investigation tasks
Investigation tasks, technical tasks, or spikes are useful tool because it allows developers to understand more aspects before they estimate.
Why do developers need investigation tasks? The idea behind spikes is to understand well enough how to do the work so you can estimate it. But most importantly, to come up with the best solution.
When teams don’t need a spike for a user story?
- When they can figure out things as they work and progress with the item
Some teams think that before starting development on an item, every single detail must be clarified
But that is unnecessary. There will always be some information they will find out during development. And that should not be an impediment for the development to start
- If the development doesn’t start right after the investigation is finished
The spike might no longer be relevant by the time implementation starts. The team might lose their knowledge or the feature might not be of interest anymore.
Final thoughts
Collaboration and transparency are key in any aspect of Agile and this includes user story splitting, too. You, as a Product Owner, are part of a team and you should work together to be efficient and release successful features.
You can leave a comment below if you want to share any of the mistakes you’ve made along the way or if you have any suggestions on how to avoid some of them.
