User stories are development tasks often expressed as follows:
persona + need + purpose
A key component of agile software development is putting people first. User stories put actual business users at the front-and-centre of the conversation.
In this post, we will cover the following topics:
- What makes a good user story?
- Story template
- Definition of “ready”
- Definition of “done”
What makes a good user story?
A user story is a placeholder for a conversation. A good story will give the team enough information to frame a discussion around the story which can be used to design and implement the solution. User stories are not meant to be exhaustive specifications.
The formula goes like:
As a <user> I want <function> so that<value>.
User stories should follow the INVEST model. Diagram follows with credit to Bill Wake:
Wha does INVEST mean?
To be successful in agile, it is worth INVESTing in user stories. Here is a summary of what each component means:
Independent: where possible, avoid creating stories that have dependencies. This is often a very difficult thing to achieve. However, stories that need to be done in a certain order make it difficult to prioritize and plan in a flexible way.
Negotiable: a story is not a specification. It is important to strike the right balance and include the right level of detail. A story with too much information creates the illusion of completeness. In turn, this gives the developers less incentive to ask questions and have a conversation about the requirements.
Valuable: stories must deliver business value. All stories, even technical stories, must include a statement that explains what business value will be delivered.
Estimatable: the team needs to be able to estimate all stories.
Small: if a story is too big, it will be hard to estimate accurately, difficult to plan and difficult to action. Larger stories tend to obscure assumptions, which can lead to issues such as creep or failure to listen to the users properly. The simple activity of breaking down a large story (an Epic) often uncovers missed requirements.
Testable: all stories must be testable. Using acceptance criteria in all stories ensures that only those items that are testable are given to the team.
Spelling and Grammar:
To be effective a story must be written in clear and correct English with proper grammar. Poor language usage can put the user story at risk, with a greater impact on the project as a whole. To illustrate, here is a classic example of how imprecise language can obfuscate a story:
Entree comes with soup or salad and garlic bread
What is being delivered in this story? (Soup or Salad) and Garlic Bread OR (Soup) or (Salad and Garlic Bread)
What does a good Story Template look like?
All user stories should have the following items:
Title: All stories will have a descriptive title
Description: A brief introduction to the story to set context. If there is a narrative, it should be included here.
Story: A story will have 1 story.
As A – describes the person or group who is the primary recipient of the value of the story. A story should only ever address one person or group.
I want to – describes the functionality that will be developed in the story
So that – defines the goal of the person or group fulfilled when the story is complete
Acceptance Criteria
A story must have at least one acceptance criteria. Any story that has five or more acceptance criteria should be split into multiple stories. Acceptance criteria should be written in the following format:
Given – sets a precondition
When – describes the action that will be performed
Then – defines the desired outcome after the action has been performed
Dependencies
There should also be a note, indicating where there are any dependencies on other stories or teams.
What is the Definition of Ready?
When is a story is “ready” to be played?
A story is ready to be played when
- It includes all of the items required on the template (see above)
- It has been reviewed with the QA to ensure acceptance criteria are documented
- It has been reviewed with a member of the development team to ensure that it is achievable
What is the Definition of Done?
When is a story done?
- A story is considered done when it is deployed and demoed to the Product Owner.
Recommended reading:
User Stories Applied by Mike Cohn
Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans
Introduction to Behaviour Driven Design by Dan North