Overview#

User Story represents a small piece of business value that a Delivery Team can deliver in an iteration. User Story (and Agile Tasks, 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:

TermDescription
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
  • Avoids introducing detail too early that would prevent design options and inappropriately lock developers into one solution
  • Avoids the appearance of false completeness and clarity
  • Get to small enough chunks (Agile Tasks) 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:
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop