Mistakes to Avoid During Story Splitting
User stories are small descriptions of what a client or user requires from software. A good division of large user stories into smaller ones will make it more understandable to everyone, and better estimable. In other words, it will bring us a little closer to our goal: success.
What Not To Do When Story Splitting
Now we will proceed to list out some of the most commonly committed mistakes in story splitting. Take a look at these and analyze them in your next stories.
1. Making Story Splitting an exclusive task for the Product Owner
One of the most frequent problems is considering Story Splitting as a task that the Product Owner must do by themselves. This is a problem because Product Owners don't really have the expertise. Most of them tend to break down a user story into a certain number of subcategories but fail to distribute the work evenly, which means they can even leave 99% of it in only one of those categories of the story. Similarly, the Product Owner might create new subcategories that depend on each other, which will ultimately keep them from being completed in one cycle.
Nevertheless, if you want the stories to be optimally disaggregated, you should have a balance between the participation of the Product Owner and the team. This technique should be seen as a team-wide activity, as many activities often are in these types of environments.
2. Story Splitting from a technical perspective
Only viewing and considering splitting stories from a technical perspective instead of functional is the second mistake. User Stories are usually written in this way: "As a programmer, I wish to..." and only state functionality from the perspective of the team instead of the one from an end-user or stakeholder. Story splitting from this technical perspective might also generate some stories like the following:
“As a user, I want a back-end that does this and that”
“As a user, I want an interface that does the same thing this and that”
Stories broken down along technical guidelines only produce stories that don't bring any worth or importance to these users by themselves. An interface (for example, a web interface) does not serve users until they interact with a backend (an intermediate layer and/or database).
3. Exposing the solution in the split story
Another commonly made mistake is mentioning the solution inside the splitting story itself. Why should you not do this? That is because the good user stories have a different focus: they talk about what needs to be executed instead of disclosing how to specifically do this. Why does this mistake get done? Well, this often happens when the story gets too split: the story reaches an already small size, but the person doing the task still keeps saying more about it, and this way they fall into details that they shouldn't be talking about in the first place
Let's look at this classic example from the best books on these matters. Suppose we are creating an ATM where people can withdraw money from. This example makes the point that when specifying what is required for this task we should not just assume that it will use a PIN code and a card for access to the user’s account just because that's how most ATMs have worked since they started existing. What it means is that maybe this time we will use a fingerprint scanner or face recognition as a way to recognize the user’s identity. What would be a good idea to start with the story then? Saying something simple like "The user identifies himself". Next, just leave out the part where you explain how this will actually be done. It is as simple as that. Of course, as your team begins to split the story more and more, it will get to a point where it might be needed to specify a little more on the technology that will need to be used to do this (which is the fingerprint scanner or the face recognition). That is not a mistake, but be careful to just mention it briefly and not take too much time or specify too much on the process that these technologies will convey.
4. Using a Spike in each story
Spikes are an important part of the whole story splitting process. A Spike is a process based on the effort that a team makes to produce new knowledge rather than new functionalities. Well, Spikes are very useful to diminish risks or uncertainties in a story. This mostly happens when a team is unsure or doesn’t really know or have much experience with a novelty technology. In this situation, you can rely on a Spike so that you can get some information and become more accustomed and comfortable around this new technology. Running a Spike can also help all the people involved in the story splitting and developing a process to experience different and better ways to break down the story if it's still too big having already gone through the Spike.
Sometimes, teams will even split a spike in every single story they develop, which is not a good idea at all. All stories have an amount of uncertainty in them, but as we have already mentioned, Spikes should only be used when there is an abnormal uncertainty, just in extreme cases. It should not be applied when a story has normal and manageable amounts of uncertainty that are common in everyday situations. The goal of a Spike should not be to eliminate all uncertainty. It will always exist.
Conclusion
Now that we discussed a few of the most common mistakes in user story splitting, you can be more aware of making them when you do this activity and apply this technique. As you might have seen, they are easy to commit, but they are also easy to avoid. Just take into consideration and apply all the tips that we have mentioned, and you will be able to get the best out of the amazing technique that story splitting is.
References
- https://www.mountaingoatsoftware.com/blog/five-story-splitting-mistakes-and-how-to-stop-making-them
- http://www.humanizingwork.com/wp-content/uploads/2020/10/HW-Story-Splitting-Flowchart.pdf
- https://contextmapper.org/docs/story-splitting/
Useful Links:
SAFe Agilist Online Certification Norfolk, Leading SAFe Online Training Jacksonville, SAFe Agilist Training Jackson, A-CSM Virtual Training Course Jakarta, Advanced Scrum Master Online Training Rotterdam, A-CSM Virtual Certification Training Surabaya, A-CSPO Course Training Iowa City, CSM Virtual Certification Training Bangalore, Certified Scrum Product Owner Certification Course Melbourne, SAFe Agilist Training Miami
