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.