User Story


User Story represents a small piece of business value that a team can deliver in an iteration.

User Story (and similar things, often called features) break requirements into chunks for planning purposes. Stories are explicitly broken down until they can be estimated as part of XP's Release Planning process.[2]

While traditional requirements (like use cases) try to be as detailed as possible, a User Story is defined incrementally, in three stages:

  • The brief description of the need
  • The conversations that happen during backlog grooming and iteration planning to solidify the details
  • The tests that confirm the story's satisfactory completion

Well-formed User Storys will meet the criteria of Bill Wake's INVEST acronym:

IndependentWe want to be able to develop in any sequence.
NegotiableAvoid too much detail; keep them flexible so the Delivery Team can adjust how much of the User Story to implement.
ValuableUsers or customers get some Business value from the story.
EstimableThe Delivery Team must be able to use them for planning.
Small as Large User Story are harder to estimate and plan. By the time of Iteration Planning, the story should be able to be designed, coded, and tested within the iteration.
TestableDocument acceptance criteria, or the Definition of Done for the User Story, which lead to test cases.

Why Use User Stories?#

Keep yourself expressing business value

Avoid introducing detail too early that would prevent design options and inappropriately lock developers into one solution

Avoid the appearance of false completeness and clarity

Get to small enough chunks that invite negotiation and movement in the backlog

Leave the technical functions to the architect, developers, testers, and so on

More Information#

There might be more information for this subject on one of the following: