TPP #006: How to break down big user stories into small user stories
Hey there!
Today I want to talk about breaking down work:
- Why I recommend breaking down your work
- How to do it while still delivering value to the user
- The benefits you’ll unlock with smaller chunks of work
Why great teams break down their work
It’s risky to work in large batches.
That applies to big user stories too. Big user stories are risky and uncertain. That’s because big user stories are harder to plan, test, deploy, and measure.
So, great team break down (or decompose) their big stories into smaller stories.
And in addition to being less risky overall, smaller user stories are easier to:
- Estimate
- Understand as a team
- Measure end-user value
- Discuss during a planning meeting
Plus, they help smooth out your team’s throughput.
That means more consistent and reliable delivery.
How to tell if your user stories are “too big”
Terms like “big” and “small” are relative and vary from team to team.
Which means it’s hard to agree on what it means for a story to be “too big.” And a lot of teams can’t estimate how long their work will take to complete. Some teams don’t even bother estimating their work. Others don’t use artificial time boxes (like sprints) so they don’t even have a concept of “too big.”
Luckily, you can use constraints to infer story size that are relative to your team.
Some constraints might be:
- Story point estimate
- Areas of system impacted
- Number of acceptance criteria
- Hours of manual testing required
- Etc.
You just need the ability to find user stories that are a lot bigger than normal.
How great teams turn big stories into smaller stories
Even though you’re breaking down the work, you still have to deliver value to the user.
And this is what makes breaking down work so challenging. Because it’s easy to slice up some work along arbitrary lines. But it’s hard to eliminate the “extra” stuff while still delivering value at the end of the day.
Here are some things to keep in mind as you go:
- Agree on areas where compromise is acceptable
- Ensure that the smaller story still delivers value to the user
- Anchor negotiations (of what to cut) around important metrics
Decomposition anti-patterns
There are some common ways to break down work.
However, they don’t produce the desired result. Sure the stories are technically smaller. But they are usually dependent on each other. And you almost never get value delivery when you ship them on their own. Assuming you even can ship them on their own.
So, it’s best to avoid these anti-patterns:
- Breaking a story down by functional area – It’s easy to split a story into “front-end” and “back-end” but you don’t get any value by delivering one without the other.
- Splitting the work where you can’t ship to production – Avoid splitting the work in a way that creates unnecessary dependencies (and bottlenecks) in your flow.
- Dividing the work across all members of the team – This works, some of the time. But teams are usually less capable of working in parallel than you think.
- Break up the work into workflow steps – Avoid breaking the work into phases like “dev” and “test” and “deploy.”
Five ways to break down user stories (that actually work)
These techniques (or a combination) will help you start decomposing your big user stories.
- Make it work, make it right – I’ve never seen a user story that couldn’t be completed today in a sub-optimal way (i.e. performance, resource allocation, architecture) that couldn’t be improved tomorrow.
- Make it work, make it beautiful – Similarly, you can always ship a slightly uglier version of a feature today and comeback to polish it up tomorrow.
- Use Feature Flags – You can drastically reduce risk, and the list of requirements, by deploying any feature behind a feature flag. Combine the first two techniques for added slimming.
- Do things that don’t scale – Sometimes the complexity of a user story is in all of the “other” stuff you think you have to do. So, look for ways to complete tasks manually, delay automation, or otherwise adopt a hacker mindset.
- Work in smaller time boxes – A great frame of mind for decomposing work is “what could we get done today?” The more extreme time constraint will force your team to get creative.
All of these techniques have one thing in common, a focus on iteratively delivering value.
Problems you’ll face when trying to break down big user stories
As you start negotiating the scope of each user story, you’ll run into problems.
These aren’t problems with the process of decomposition. Instead they’ll symptoms of other, larger, problems on the team or in your organization. Solutions will vary from team to team. But having awareness will help you get ahead of them. That way, you don’t give up on breaking down big user stories.
These are just a few of the problems you might face:
- You may accidentally highlight silos on your team.
- Sometimes it’s to get buy-in from the business on “doing less.”
- The system you’re building isn’t ready for frequent delivery of value.
- Some features will be held hostage by uncompromising stakeholders.
- It necessitates a lot more creative thinking during planning (and time spent planning.)
- The product owner (or business proxy) doesn’t actually know what drives user value.
Nothing you can’t overcome with time, but definitely roadblocks when you adopt this new approach.
Clay’s Notes
My key takeaways:
- Don’t get discouraged when the going gets tough.
- Decompose your big stories to reduce risk and smooth throughput.
- Always focus on delivering value, no matter how you break down work.
- Negotiate each story to see where you can reduce scope today, and improve tomorrow.
Is there something about decomposing user stories that I missed? Hit reply and let me know.
Until next time!