Story Design

INVEST

Stories should follow the practices of the INVEST acronym.

• Independent: Stories should be independent from each other so that they can be implemented in any order. Since absolute independence is not always possible, try to reduce dependency to a minimum.
• Negotiable (between developers and business): For example, if developers have an idea for a realization that is easier/cheaper to develop but different from the stakeholders' vision, this should be discussed.
• Valuable: The story must have clear value to the business. Refactoring, architecture, and code cleanup are not valid stories. Developers need to address these concerns when they implement the actual stories. The Bill of Rights guarantees them time for these tasks.
• Estimable: Must be concrete enough for developers to estimate.
• Small: The story implementation should fit into one iteration and require 1-2 developers at most. Roughly 1-2 stories per developer is a good guideline.
• Testable: The business should be able to articulate tests that verify that the story is complete. See Acceptance Tests.

Ignore Details and Delay Specification

On the one hand, our knowledge grows as the project progresses. The later we make decisions, the better informed they are. On the other hand, user stories evolve, merge and split over time, so early user story specifications can become obsolete, resulting in wasted effort. For these two reasons, it's best to delay specification as long as possible, which means that user stories should remain generic and not contain details. User stories should be specified in detail when they are implemented.