A guide to Writing Effective User Stories

In an agile organization, the User Story replaces traditional requirement documentation. While traditional requirements like functional or user interface specifications try to be as detailed as possible, User Stories break down the business requirements into the smallest piece of business value that a development team can deliver within an iteration.
That said, there is an art to writing effective user stories and UX designers cannot simply rename their User Interface Specifications to User Stories. Use the following guidelines to consistently deliver requirements that can be easily understood by your development teams.
Choose the right amount of detail
The size of the user story should be small enough to code and test within an iteration. The size of the story determines its classification within Agile (Initiative > Feature > User Story)

  • Initiatives are large stories – too large to develop and test within an iteration
  • Features are smaller stories within an Initiatives – still too large for an iteration
  • User Stories are the smallest chunk of work that can get completed within an iteration

Effective user stories should follow the INVEST acronym championed by Bill Wake a leader in the agile arena.
Follow a consistent format
When writing user stories use the template below to guide the story in a way that’s easily understandable and consistent across development teams.

Story Name

{ high-level descriptive text for the story }

Value Statement

As a  { insert user type }, I want to { insert description of the the capability or task } so that { insert description of the benefit or outcome }.

Acceptance Criteria

Show me …{ insert the critical details of the story and/or pieces of functionality that you want built }

NOTE: List as many acceptance criteria as possible in order to clarify the intent of the story. Regardless of how detailed the acceptance criteria are, the team will have conversations about them and adjust the acceptance criteria as needed.

Definition of Done

{ insert the team’s standard for story completion – does not change from story to story }


{ attach additional details like, persona, supporting documentation, mockups or prototypes related to the story }

Focus on what makes a user story effective

  • Define development team efforts in terms of business value
  • Prevent the business from introducing too much detail too early which can lock the development team into one solution and prevents the exploration of alternate options
  • Avoid the appearance of false completeness and clarity
  • Are small enough to invite negotiation and movement in the backlog
  • Leave the technical functions to the architect, developers, testers, and so on