Do you find it difficult to split complex user stories? Do not worry, it’s a common thing that happens among many teams.
Some teams don’t break down such stories because it’s difficult to find the value behind each subpart of the story. But even if it’s a laborious task sometimes, as a team, you should decide how you’ll treat that working item.
User stories are divided into two categories:
- Compound user stories
- Complex user stories
Compound user stories are working items that comprise multiple smaller user stories.
Complex user stories are the ones that many times are difficult to split. You’ll find it challenging to pull subparts of them into separate stories.
However, you don’t want to let them stay open for 2, 3, or more sprints. Velocity will become unreliable, and it allows teams to get used to leaving incomplete work at the end of the iteration.
If you want to know what to do so you don’t worry again about how to split complex items, I’ve listed four different tips below.
1. Split to get the smallest testable component
When you don’t know what to do about a complex user story, here is what you can try.
- Identify what is the smallest part that you could test, without having the entire feature ready
- Extract it from the whole and create another user story
- Check if you can repeat the process with what you left from the initial story
- Don’t worry if you cannot deliver each piece individually
Many times, a user story can be tested while being developed. So it’s unnecessary to wait until the developer finishes the implementation.
If you can identify pieces that the team can test during the process, then you’ve got yourself a way to break down that chunk of work.
2. Identify checkpoints for the complex stories you won’t break down
Sometimes even these methods are difficult to apply. And thus, we decide that the best thing we can do is to move the story from one sprint to another.
However, this should not be a rule. And the first thing you should do when you have a complex story is to try splitting it.
Even in this case, we have to keep track of the effort the team is investing into that item in each sprint.
How do we do that?
- Identify together with the team in what stage can you bring the item sprint by sprint
- Set milestones; this will be the goal the team should aim at in each iteration
- Besides the estimate that you assign to the complex working item, add estimations to each milestone as well
What are the benefits of setting such milestones?
- The velocity of the team won’t suffer as long as we set these milestones and assign story points to them, as we do with the complex story
- The team will feel that at the end of the sprint they met a goal, even if it’s a small part of the larger scope
3. Split the complex user story into smaller ones even if you won’t deliver each story separately
If I were to guess, you are now probably asking yourself the following question: What about the value we have to deliver at the end of every iteration?
Let me tell you this. Agile is about being flexible, about reacting to changes, and not about following rules at all costs. Sometimes you won’t have the possibility to deliver a feature in production in only one sprint. And that is fine.
With Agile, we build in increments. With each iteration, we build on top of what we did in the last sprint. So there will always be a certain level of dependency from one sprint to another.
But do not fall into the trap. At the end of every increment, we should be able to at least review what the team worked on. If the Product Owner has to look at some scripts written by the development team, that’s not good.
Why is it not mandatory to release a feature into production at the end of every iteration?
- We can show the progress we make each sprint.
- We work with potentially releasable increments
One of the most important purposes of delivering working items at the end of every sprint is early feedback. However, when we don’t have something entirely shippable, we can show the progress we make towards the goal. And get feedback for that smaller piece.
The Scrum Guide says this: “The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint”.
Scrum can be used in many situations. Some teams may have releases in each sprint or multiple times in the same sprint. Others build increments that need more iterations to release.
4. Do not implement in one iteration and test in the next one
If you take a complex user story and split it into implementation and testing, you’ll get yourself working in waterfall phases.
Why we shouldn’t break down complex user stories into separate phases?
- Inconsistency is being introduced from sprint to sprint
- It will be more difficult to regroup after this user story so that you can deliver the other user stories in time
You can easily imagine what will happen if the developer finishes his work in one sprint, then the tester invests all of his time to test the story in the next sprint.
You will have to reduce the work that you can take into the next sprint for both testers and developers. And that’s because you have one tester less. And you will be doing all the planning around this user story.
There will always be one exception at some point, but user stories must always be testable.
When you split user stories, no matter if they are compound or complex stories, you have to take into account a couple of things. Make sure that you create and split your stories based on the INVEST criteria and vertical slicing principle every time this is possible.
