Writing Effective User Stories

posted in: Scrum | 0


Stories should adhere to the following guidelines.


  • Dependencies between stories lead to prioritisation and planning problems.
  • Split one story into many or combine more stories into one.
  • Higher priority stories should never have lower priority dependencies.


  • Add one/two line sentence with notes. Notes should qualify, but not have too much information.
  • The story is a promise for a conversation.
  • A story card with too much detail, might lead the developers to believe that ALL information is concrete and all detail correct. This can lead to error is weighting.
  • Details that have been determined in conversation becomes tests.

Valuable to purchasers or users

  • Avoid stories that are relevant to developers eg. All connections to the database are through a connection pool vs. Up to fifty users should be able to use the application with a five-user database license.
  • It is worth attempting to keep user interface assumptions out of stories
  • It is also worth keeping technology assumptions out of stories.
  • The best way to ensure that each story is valuable to the customer or users is to have the customer
  • write the stories. (Ask the question: ”What is the value that the client will see when he reads
  • the story”).


Reasons why a story may not be estimatable

  1. Developers lack of domain knowledge.
  2. Developers lack of technical knowledge. Use a Spike (brief experiment to learn about an area of the application) to obtain relevant domain knowledge.
  3. The story is too big.


  • The ultimate determination of whether a story is appropriately sized is based on the team, its capabilities, and the technologies in use.
  • Compound stories can be split into smaller stories.
  • Complex stories can be split into research (spike) and implementation. Best practise will be to
  • do one in one iteration and the other, in the next.
  • Smaller stories can be combined to form a bigger story that can be estimated.


  • Untestable stories commonly show up for non-functional requirements, which are requirements
  • About the software but not directly about its functionality eg. A user must find the software easy to use.
  • Strive for 99% automation.

Writing the Stories

Some guidelines that are working well for us.

General Syntax

A few of many…

Convention 1

As a (role the author represents)
I/we (can) (do or have something with these qualities)
to achieve (my goal or objective)

Convention 2

As a (role),
I can (do or have something with measurable qualities)
to (achieve a business goal)

Convention 3

To (achieve a business goal),
(roles) can (do or have something with measurable qualities).

Use active voice.
Story should be limited to one or two brief sentences.


Some rule that a story can be tested against.

Keep the user story simple

  • State one thing (single thought)
  • No IF, AND (if it creates compound sentence) or BUT
  • Prevent limiting phrases (unless or except)

Emphasises WHAT should be done and now HOW it should be done

  • No preconceived solutions
  • Business result NOT technology
  • Destination NOT Journey

Effective user story is relevant to the project

  • Stories that are relevant to the project in that it falls within the charter/scope statement
  • Defines business need or want
  • Has a short tail – No cascading changes

Remove ambiguity

  • Try to misunderstand story
  • Desk checking – Re-evaluate story at different time and location
  • Ask someone to rewrite NOT using any of your words (nouns, verbs, adjectives, adverbs)
  • Make the story easily understandable
  • Should be unambiguous
  • Clear to all target audiences

Non-functional requirements add value to user stories

  • Measurable from user perspective.
  • System should be user friendly.
  • System should be fast.


Thanks to the Mountaingoat and Business Analysis Experts for their insights.

Leave a Reply