Maximizing Business Value with User Stories

Businesses place great value on stories because they provide a vertical slice through the layers of the system and help teams focus on product behavior rather than its construction.

Some teams use informal scales such as high/medium/low or a ten-point scale to quantify business value. User stories should be independent to allow implementation in any order. While they should be concrete enough for developers to estimate, they should contain only some implementation details.

A user story should have clear and quantifiable value to the company and should not be larger than what one or two developers can implement in a single iteration.

The specifics can be negotiated between developers and the business. The number of stories per iteration should match the number of developers on the team. Valuable but inexpensive stories should be done immediately, while valuable but expensive ones should be done later.

Affordable but valuable stories may be completed eventually, and costly but non-valuable stories will never be done.

The best predictor of iteration progress is the previous iteration.

The project is ongoing until all the stories are implemented, and it’s over when there are no more stories in the deck worth implementing.

User stories encourage sharing the model of how users think about the system, allowing teams to consider product use rather than construction.

Debating and analyzing ideas becomes easier when expected behavior is defined in a shareable form.

Refactoring, architecture, and code cleanup are not stories.

For a User Story to be considered complete, more is needed than simply passing technical and functional tests.

The crucial factor is behavior change.

To ensure that the expected change takes place, it’s important to quantify it in an observable and measurable way.

When identifying a change, ask yourself, “How much will it cost?” to ensure its significance. Valuable initiatives produce an observable change in someone’s way of working.

Capturing a behavior change makes a story measurable from a business perspective, always opening up a good discussion.

Often, the short description of a story leaves a lot of ambiguity about the scope of the change.

Even when it is being discussed face to face, it may only be apparent to some the full implications of taking on the story. If you have a big chunk of work, identify underlying assumptions and think about the easiest way of proving or disproving them.

Design experiments around those assumptions and turn them into user stories.

Use the experiments to build the foundation so that the rest of the big picture can be delivered with minor iterative improvements.

When the deliverable is outside the zone of control of the delivery team, there are two everyday situations: the expectation is completely unrealistic, or the story needs to be more actionable by the delivery group.

If a user story definition does not fit into the expected pattern, raise the alarm early and consider re-writing it.

Micro-stories aren’t necessarily bad, but going so deep into detail is overkill for anything apart from short-term plans. If you discover micro-stories on medium-term or long-term projects, replacing a group of related stories with one more significant item is better.

Even planning to check the outcome after delivering a story makes teams write better. It has the same effect as test-driven development does on code. It provides focus and clarity and leads to better solutions.

Technology shouldn’t be used just for the sake of using it.

Before implementing new technology in an organization, evaluating its potential benefits is crucial to ensure it provides a tangible advantage to the business. Any other reason for using it should be carefully compared to the associated risks and costs.

To determine the business value of technology, it’s necessary to evaluate how it will influence the behavior of key stakeholders affected by its use.

Suppose the technology doesn’t offer a way for actors to move beyond the current system or interact with it at a deeper level. In that case, the risks of implementing it outweigh the potential benefits, leading to expensive development cycles and possible failure.

Ultimately, technology should always be a means to an end, and that end should be achieving business value.

[¹]: User Story Mapping: Discover the Whole Story, Build the Right Product