Focusing User Stories to Deliver Business Value
A story is always something that the business values. Think of a story as a thin vertical slice through the horizontal layers of the system. Quantifying the business value can be informal. User Stories make the team focus on how the product will behave rather than how it will be built. User stories are independent of each other. This means they can be implemented in any order. User stories should not contain every detail for the implementation. We want those details to be negotiable between the developers and the business. A user story must be concrete enough for developers to estimate it. The story must have clear and quantifiable value to the company. A user story should not be larger than one or two developers can put in place in a single iteration.
Quantifying the business value can be informal. Some teams might use high/medium/low as their business value scale; others might use a ten-point scale. An iteration should contain about the same number of stories as there are developers on the team. The stories that are valuable but cheap will be done right away. Those that are valuable but expensive will be done later. Those that are valuable and inexpensive might get done one day. Those that are not valuable but are expensive will never be done.
The best predictor of the progress of an iteration is the previous iteration. The project is still ongoing when all the stories are implemented. The project is over when no more stories are in the deck worth implementing. The main advantage of User Stories is sharing the model in which a user thinks about the system. Instead of focusing on how to build something, delivery teams consider how their products will be used. Ideas can be debated and analyzed by defining the expected behavior in a shareable form. Refactoring is never a story. Architecture is never a story. Code cleanup is never a story.
Generic user roles are often a get-out-of-jail-free card for people who want to push in pet features or unjustified scope. A specific user segment must decide whether a solution is right or unnecessary scope creep. The user segment helps narrow the actors the story is trying to support. Check the user segment to plan releases, measure impact, or discuss completeness. Avoid *’ as a user* statements like the plague. Avoid generic customer segment descriptions of any kind. Identify and describe user segments to help ease productive discussion of needs and solutions.
Precise and accurate user role help identify needs and remove unnecessary complexity. Once you understand who will use the product you’re building, it becomes possible to compare different solutions. Offer alternatives, or even discard features that won’t fit. For internal IT or enterprise projects, identify the people using the target system and investigate how work is divided. Different departments or areas of focus will help you identify helpful user segments.
Approaching stories as survivable experiments, we can shift the focus from technical complexity to expected learnings. Survivable experiments prevent stories that business sponsors don’t care about from going live. It also reduces the number of Fake User Stories in the backlog. Small, valuable user stories — Small, releasable accounts limit dependencies’ scope, simplifying multi-team coordination. User Stories that are easy to follow and make sense in the context of a problem follow certain principles that make them so.
