Guidelines

User Stories should adhere to the following guidelines.

Independent

• 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.

Negotiable

• 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 in 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”).

Estimable

Reasons why a story may not be estimable

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.

Small

• 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.

Testable

• 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 might help you.

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.
A Story should be limited to one or two brief sentences.

Rules

Some rules 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)

Emphasise WHAT should be done and not HOW it should be done

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

Effective user stories are 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 the 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.

References

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