What Makes a Good User Story — Part 3
Now we’re getting down to the nitty-gritty. In this post, we’ll talk about debugging your user stories by making sure they’re just the right size.
Getting Your Stories to the Right Size
From our first post, we learned that creating truly independent stories is a hard skill that takes time to get the hang of, but done right, it opens up the team for fast execution.
Getting stories to the right size makes them easy to understand and easy to estimate, which is agile gold for the team. Small stories are great because they let the team deliver value fast and avoid context switching by packaging requirements in achievable chunks of work. Stories that are small also create predictability in estimation results, which project managers love.
So how do you know if your story is too small or too big?
If your story is too big, the team will tell you. Really.
That’s the first and easiest tip-off, but if you’re still having trouble figuring out how much is too much and you’d rather finesse things first before presenting to the team, here are several tells:
- Your requirements span more than half a page of whatever requirements management tool you use.
- Your requirements have a lot of qualifiers
— e.g., IF a AND b AND c, then… OTHERWISE IF x AND y AND z, then…
- Your story addresses more than one step in the user workflow.
- Your story contains all the workflows! Happy path, alternate workflows, all the exceptions… (your user story will be running off the page!).
- Your story addresses all CRUD operations for a process.
- Your story addresses more than one user role.
- Your story addresses more than one or is overloaded with many data types.
- Your story addresses more than one business rule.
- Your story addresses more than one form factor and/or device.
- Your story contains too many unknowns for the team to estimate.
- Your story’s going to take a long time to get to “Ready” on the board.
Split those puppies up.
What if your story is too small? This is a subtler pattern to catch.
But there are still signs:
- Your story only addresses technical tasks, i.e., does your story actually describe a feature? Or just a technical to-do?
- Your stories are intentionally being sized small enough so that they can fit into a sprint.
- Your stories are being split horizontally per the technical expertise of the team, e.g., a UI story, a backend story, and an API story together all achieve a single new feature.
- Your story is written for users like a “product owner,” “technical manager,” or “developer.”
Examples like the above create stories that have one revealing factor you can watch out for — these kind of user stories don’t generate business value. When this happens, it’s better to step back, focus on the who, what, and especially the why of the story, and then:
- Focus your stories first on the most important user actions for your users, and remember the Pareto principle: in software development, 80% of your results will come from 20% of your efforts. Or said another way, 20% of the product backlog will produce 80% of the business’ profits. So, focus your stories and the team’s work on the most important 20%.
- Divvy up your stories in vertical slices. Unlike horizontally-sliced stories, vertically-sliced stories are tech-stack agnostic and allow you to parcel out functionality at the finest granularity. Slicing stories in this way maintains business value and avoids siloing the team and impeding the team’s progress.
- When in doubt, slice your stories in such a way that something can be deprioritized.
If your story is the right size, clear and easy to understand, the team should be able to take it from there. They’ll talk about how the story fits into the existing features, the codebase, the domain model, and so on (if these things already exist or if they need to be created), and discuss what tasks need to be performed.
They’ll put an estimate on the story, and that’s it! You’re ready to start delivery, and it’s all downhill from there! ;)