Struggling with long-lasting story implementation and the risks it bears with it? Here are four simple ideas for user story splitting:
Split stories by scenarios
Have you ever got stuck with a user story on your board not moving anywhere forever? Do other user stories seem to get done much faster?
There are many possible reasons, but chances are that the item is too big. And many of those reasons have the same root.
Don’t be afraid to split stories. There are many ways to do it, but here is an easy one – look for the single scenarios or functional paths.
Each scenario is a good candidate for an acceptance criterion anyhow. Splitting by acceptance criteria formulated this way is the easiest and least expensive way to go.
The usual excuses for not doing so encompass the following:
- It is not a complete feature
- This cannot go into production
- We cannot market this
And these are all more or less true!
However, splitting stories using this technique will most probably get you the following:
- Having more reliable verification and validation by having easy-to-understand scenarios, so the quality goes up
- Getting the feedback more quickly (not necessarily from the clients, but from the system, peers, tools, etc.)
- Achieving incrementalism more easily
- Establishing a more stable and predictive flow of work and value through your process
Don’t be afraid to split stories!
Big stories invite multitasking
Does something often pop up, messing up the priorities of the user stories already in progress? How big are your user stories?
Working on big stories invites multitasking. The longer your user story lingers in your process, the higher the probability that more important things will come up while you still work on it.
Teams usually respond to such challenges in one of the following ways:
- Stopping working on the big story already in progress and switching to the more important thing, or
- Assigning a part of the team to the more important thing, or even
- Starting multitasking on both things at once
Either way, the team ends up in some form of multitasking, given the cognitive separation of team members.
Multitasking is defined as:
Multitasking (n.) – The performance of more than one task at the same time.
However, in cognitive-heavy environments (e.g., SW development), the following often stands to be true:
Multitasking (n.) – The act of screwing up several things at once.
Split stories to a smaller size, so the chance of having to work on multiple things at once is minimized. This allows work to flow through your process in a more controllable manner.
Splitting reduces risks
Know that feeling of frustration when something blocks the progress of your work on user story implementation? What if you could know those things sooner?
Working on novel ideas inevitably bears a risk with it. Sometimes those risks are obvious, but some are hidden very well until you thread on them.
The larger the user story, the greater the chance that both of those kinds of risks are in the story you are working on.
If you want to handle them more effectively, story-splitting is your ally!
Large stories often seem like a big ball of mud, risky from whatever side you try to approach them. Trying to split them thoroughly through a single story-splitting workshop often proves ineffective, due to the sheer amount of risks and unknowns involved.
A large user story is not a piñata, which can effectively be split with a single blow.
It is rather a multiple-layered onion. Reduce risks as you peel layer after layer from it. As soon as there is a risky layer, make an experiment on how to reduce it, and do it as soon as possible.
These simple steps explain how to do it:
- Start with clearly stating what you know and what you understand.
- Chip those things away from the unknown part.
- Come up with a small experiment to better understand the big unknown on your table. Chances are that you are going to understand it better.
- If you do, repeat the step of chipping the known part away from the unknown and repeat the process.
- If not, repeat the process anyway, and try the new experiment.
Split stories and reduce the risk!
Do it at the last responsible moment – just BEFORE starting the implementation.
Keep stories small and simple
This story will be done when it is done!
How often have you been in such a hopeless place, not clearly understanding what else is left to complete the user story?
Having no deadlines does not mean that any work item is allowed to spiral out uncontrollably. However, not having clear expectations within a team implementing a user story often invites working in large batches.
™No! I am not working on a large batch! I am working on a single story!™
How big or how small is your story?
Try this to find out:
- Exercise different scenarios within the same story.
- They all become different use cases.
- Every single case becomes an acceptance criterion.
- Every acceptance criterion is a good candidate for a separate story.
- The more criteria you have, the larger the batch is.
Keep your stories small and simple!