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
- Developers lack of domain knowledge.
- Developers lack of technical knowledge. Use a Spike (brief experiment to learn about an area of the application) to obtain relevant domain knowledge.
- 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.
A few of many…
As a (role the author represents)
I/we (can) (do or have something with these qualities)
to achieve (my goal or objective)
As a (role),
I can (do or have something with measurable qualities)
to (achieve a business goal)
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
- 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.