Anatomy of a User Story
Basic
difficulty
Stage 1-3
Agile IQ® Level
Backlog Items
Artefact
Introduction
While it’s easy to write “as a user”, there are many more parts to a great User Story, including:
- Acceptance Criteria
- High level solutions and designs
- Sketches and diagrams
- Wireframes
- Developer notes
The Basics
Identify:
- The user. If you use Personas, insert the Persona.
- The user’s problem that needs solving.
- The reason the user needs a solution.
Watch out for
The “User” in the User Story is a person, end user, customer or persona. It’s not:
- You.
- Your team.
- Your organisation.
- An IT system or component.
- An application.
Don’t use the User Story format when:
- There is no user. This is a system interaction only.
- The item is for the organisation.
- When the work is for the team. E.g. you don’t write “as a team member”.
In these cases, use other formats like:
- I.N.V.E.S.T.
- Three Cs – Card. Conversation. Confirmation.
Acceptance criteria
There is often a preference for how features will work. This is often based on business rules, compliance needs, or process-driven requirements. These are often written as “acceptance criteria”.
Write the acceptance criteria as bullet points
- Must not use an invalid credit card number
- Must not use an expired credit card
- Must include the CCV / security code
- Must apply 5% surcharge
Date-driven criteria
If the item needs to be delivered by a specific date, write the date and any related rationale as part of the acceptance criteria.
Behaviour-driven criteria
When there is a workflow or user experience that is expected of the User Story, write a this as acceptance criteria. GIVEN/WHEN/THEN format is useful pattern to use.
GIVEN I’ve got items in my shopping card
AND I get to the payment area
WHEN I enter the data
THEN it validates the credit card information
AND THEN I receive a message indicating the information is correct before it asks me to submit the data
Benefits of Given, When, Then
Some of the benefits of using this approach:
- Natural language is easier for a broader range of stakeholders to understand
- Increases communication amongst team members
- You define behaviours rather than tests
- Provides visible results
- Forces separation of pre-conditions and post-conditions
- Tests focus on one scenario so troubleshooting is easier
- Opportunities to automate code directly from BDD test definitions
When dealing with software development, many programming tools such as Cucumber and JBehave provide test features that accommodate tests defined in the Given-When-Then format. Though this is the case, the approach to testing business requirements is not limited to software products.
Estimation
An estimation for each User Story provides the Product Owner with important information on:
- How large the item is
- Whether it will fit into a Sprint or not
- The size will relate how much budget needs to be spent to deliver the item
- Why the item is needed and by whom
Estimate the size of the work needed for the whole team to deliver to meet the Definition of Done.
Watch Out For
- Be careful not to write overly-complicated test statements. It may be better to split out into multiple tests.
- Update the “Definition of Ready” such that quality requirements are testable using the Given-When-Then format before teams start working on Product Backlog Items.
References
1. Manifesto for Agile Software Development. https://agilemanifesto.org
2. TDD. https://www.agilealliance.org/glossary/tdd/
3. Behaviour Driven Development (BDD). https://www.agilealliance.org/glossary/bdd/
4. Fowler, M. (2013) Given When Then. https://martinfowler.com/bliki/GivenWhenThen.html
