Child pages
  • Introduction to User Stories
Skip to end of metadata
Go to start of metadata
On this Page:

Focus on Value 

Traditional methods of requirements gathering, such as Use Cases, tend to be as detailed as possible. This is problematic. Why? Because it means gathering too many details early on–before anyone truly understands what is required.

User Stories shift the focus from writing about requirements to talking about them. 

They are written using the following format:

As a [specific type of user] , I want/need [some functionality] so that [ I can accomplish some task/goal].

Using this format keeps the focus on delivering value to the user.

It also does the following:

  • It keeps the focus off writing about technical tasks.
  • It avoids introducing details too early–details that could inappropriately lock developers into one solution before they can explore other options.
  • It keeps the team from assuming that they have all the answers up front–what is sometimes called "false completeness and clarity."
  • It keeps requirements in small enough chunks so that they can be negotiated and reprioritized in the work backlog and so that teams can more accurately estimate the level of complexity and effort required to realize the story. 
  • It leaves the technical decisions to the technical team–where they belong.

The INVEST Model

Well-formed stories meet the following criteria:

Independent:  The team should be able to work on user stories selected for a sprint or iteration in any sequence.

Negotiable:   Avoid too much detail. Keep stories flexible so the team can adjust how much of the story to implement, or so that discussions may lead to an alternate, better solution.

Valuable:   Users or customers must get some value from the story. This is the "...so that i can..." part of each story.

Estimable:   The team must be able to estimate the complexity and effort involved in realizing the story. If the story is too large, or too vague, the team cannot do this.

Small:   Large stories (known as Epics) 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.

 Testable:  Document acceptance criteria, or the definition of done for the story, which leads to test cases.

Examples

As a hearing-impaired user of the online course materials, I need ready access to transcripts of the instructional videos so that I can access the videos' content and learn from it.

As a student taking final exams, I want to see my exam score online so that I don’t have to wait until the next day to know whether I passed.

As an Audible.com customer, I want to save my favorite books in a wish list so that I can come back later to purchase and download them.

Types of Users

Try to avoid the generic role of User when writing user stories. User stories are about all of the role who interact with the system or who realize some value or benefit from the system.

Not all actors are end users. For example, a role could be another system or someone who wants certain functionality in order to buy your product but will never actually use the product. It may be useful to create aggregate roles (such as consumer) and specialized roles (such as browser or frequent shopper).

More About User Stories

Also See

 

  • No labels