Skip to content

Stories

A user story is a promise to have a future conversation; it is not meant to document every aspect of the work, as you might in a series of traditional requirements statements. (source)

In initial phases, user stories can be captured in various mediums, from documents to project management software to index cards. Ultimately, stories should be captured, tracked, and prioritized in the issue-tracking software.

How user stories help

  • Shifts the focus from writing to talking
  • Leverages natural language
  • Focuses on functionality rather than system components
  • Builds empathy for the user
  • Encourages flexibility and collaboration

What is user story?

A user story is an informal, natural language description of one or more features of a software system. User stories are often written from the perspective of an end user or user of a system. (source)

Story format

A user statement contains the role, activity, value expressed in the following format:

As a ___
I want to ___
So that ___

Acceptance criteria

Acceptance Criteria is a set of defined requirements that must be met in order to mark a story complete. This helps the team to identify if the story is done or not, as it should be simple to test the product increment against the acceptance criteria. Often this is written in Gherkin

  • Written as a set of statements
  • Accompanies the story
  • Each statement contains clear outcomes and pass / fail criteria
  • Describes the intent, not a solution
  • May include happy path, exceptions, or edge cases

INVEST

The acronym INVEST helps to remember a widely accepted set of criteria, or checklist, to assess the quality of a user story. If the story fails to meet one of these criteria, the team may want to reword or refine it further. (source)

Characteristic Guideline
Independent Can it be delivered independently?
Negotiable Is it descriptive enough to support team debate and conversation?
Valuable Will it delivery customer or business value?
Estimable Is it clear or realistic enough that the team can provide an estimate?
Small Can the team take the story to its definition of done by the end of thr sprint?
Testable Does it clearly indicate when "good enough" has been reached?

Vertical slicing

Traditionally, requirements were broken down to fit within an individual layer of an application's stack. To produce working software in agile iterative development, teams should vertically slice stories in order to demonstrate progress across all the components in the project. This refers to a cross-sectional slice through the layers that form the structure of the software code base. (source)

For more information on vertical slicing, see Thin Vertical Slices

Vertical Slicing

Story splitting

As stories are initial discussed, often it is either too big or there are missing details. Splitting stories is a technique to break the work down by stories using its acceptance criteria. The result of story splitting is that each smaller story contains a more granular level of detail.

Story Splitting

Best Practices