Agile Zone is brought to you in partnership with:

I am an author, speaker, and loud-mouth on the design of enterprise software. I work for ThoughtWorks, a software delivery and consulting company. Martin is a DZone MVB and is not an employee of DZone and has posted 83 posts at DZone. You can read more from them at their website. View Full User Profile

Martin Fowler: User Stories

04.24.2013
| 22855 views |
  • submit to reddit

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.

Mike Cohn wrote what is now the standard book on writing user stories. To understand the roots of user stories in XP consider the white book, or the tasteful green book. In an earlier bliki entry I discuss why UseCasesAndStories are different.

Published at DZone with permission of Martin Fowler, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)