This post originated from an RSS feed registered with Agile Buzz
by Martin Fowler.
Original Post: Bliki: UserStory
Feed Title: Martin Fowler's Bliki
Feed URL: http://martinfowler.com/feed.atom
Feed Description: A cross between a blog and wiki of my partly-formed ideas on software development
User Stories are chunks of desired behavior of a software system.
They are widely used in agile software approaches to divide up a
large amount of functionality into smaller pieces for planning
purposes. You also hear the same concept referred to as a
feature, but the term "story" or "user story" has
become prevalent in agile circles these days.
Kent Beck first introduced the term as part of Extreme
Programming to encourage a more informal and conversational style of
requirements elicitation than long written specifications. The
essence of a story can be written on a single note card (Kent and I
prefer 3" by 5"). Stories are deliberately not fleshed out in detail
until they are ready to be developed, you only need enough
understanding to allow prioritization with other stories.
Bill Wake came up with the INVEST mnemonic to describe the
characteristics of good stories:
Independent: the stories can be delivered in any order
Negotiable: the details of what's in the story are co-created
by the programmers and customer during development.
Valuable: the functionality is seen as valuable by the
customers or users of the software.
Estimable: the programmers can come up with a reasonable
estimate for building the story
Small: stories should be built in a small amount of time,
usually a matter of person-days. Certainly you should be able to
build several stories within one iteration.
Testable: you should be able to write tests to verify the
software for this story works correctly.
A common way to formulate stories is the "As a … I want … So
that …" form. The "As a" clause refers to who wants the story, "I want"
describes what the functionality is, "so that" describes why they
want this functionality. The "so that" part provides important
context to understand to help get from what the customer think they
want to providing what they actually need.