Good user stories are at the heart of team workflows and facilitate a clear way forward by focusing on simple and clear business value in line with business goals. These user stories most often provided through the Product Owner of the team. As defined in XP, the 3 critical aspects of a User Story are Card, Conversation and Confirmation. Very briefly, the Card is the starting point which allows everyone to understand what the goal of the story is. The Conversation happens between the team, customers, and stakeholders which surface good questions to flush out the expectations and reasoning to get a better understanding of the requirement. The Confirmation is the agreement or the acceptance criteria created in oder to meet the needs defined form the Conversation. Despite appearing simplistic, writing user stories can be quite challenging and take some practice. Over time writing user stories generally improve as domain knowledge and relationships develop. This post shares just some very basic techniques to help you on your way.
To start off, Roman Pichler provides some useful insights through 10 Tips For Writing Good User Stories.
In line with the tips defined above, some of the key points I like to embrace with teams tend to focus on the following :
- A good acronym to refer to when creating user stories is to consider INVEST User stories should be Independent, Negotiable, Valuable, Estimable, Small, Testable
- The popular story format “As a (user role), I want (function) So that (benefit)” helps you get the focus right. You don’t always need to conform to this structure, but having a simple way of identifying the user, the action and the value delivered helps focus the conversation and encourages value focused questioning.
- A story is not a specification, and it does not replace a dialogue.
- Story writing is teamwork. Although the user story might have most of the requirements in place, it should not be considered complete specification. To get a user story into a ready state requires team conversations, feedback, opinions and questions to be sure everyone in the team understands what is being asked and understands the value. User stories are not items of work to assume and assign to individuals.
- Use language that is easy to understand and focuses on the customers value. Avoid using technical jargon which abstracts information and makes it difficult for the whole team to understand. Think if anyone walking past the board picked up the story, would they understand what’s being delivered?
- Don’t forget the acceptance criteria. To meet the user story goal, conditions of acceptance provides clarity and depth. This emerges via team conversation.
- Keep your stories visible. Visible stories not only radiate progress and status, but they promote conversation and valuable feedback which can increase a stories value impact.
- User stories have to have a clear business value, which is driven by the Product Owner to reach the business goals. Clear business value is the currency to negotiate and present priority.
- User Stories are created by the team through a team conversation. They should not be created and pushed onto others, which breaks the conversational model and reduces the impact of the solution for many reasons.
- Defining different classes of User Stories such as Bugs, Spikes or Chores are still subject to prioritisation by value through the product owner and team. Different classifications should not be used as back doors to get personal preferences on the board which by-pass the teams planning and conversational practice.
Putting this into practice
When looking for a way to structure Acceptance Criteria, ‘Gherkin’ style formatting which has emerged from BDD can provide a simple solution. If you are using BDD tools such as Cucumber, you will already know how valuable this practice is to Agile teams. This not only provides the ability to functionally test features, but tests are easy to read using a language that everyone understands, which is very powerful in getting people working together. This also allows the practice of living documentation which grows with the development of each of feature. If you’re not using BDD, I would highly recommend looking into it, but this is a topic for another blog post.
You don’t have to have Cucumber in place to format user stories in Gherkin format, you could start by using this language on the User Story for acceptance criteria. This format creates a simple common language which enables anyone to look at a card and understand it in it’s simplest terms. Let’s take a look at some simple examples :
As A (role)
I Want To (do something)
So That (benefit)
In order to (business value)
As a (user)
I want to (gain outcome)
Acceptance Criteria :
Given (the starting point/initial state)
Basic User Story Example
Lets say we want to search for a book that is listed in the store.
As A teacher
I Want To search for a book using the title
So That I can check the price and availability
Given that I am on the home screen (known state)
When I enter a book title into the search field for a book which is in stock
And press search (action)
Then I should see a list of all matched books by title
And this list should be presented in alphabetical order in Ascending order
And next to each result I should see the price and stock level (outcome)
Given that I am on the home screen
When I enter a book title into the search field for a book which is isn’t in stock
And press search
Then I should see a message indicating the book is not in stock
Remember this is a team conversation and more criteria will emerge which could also alter the main part of the story. When breaking up the acceptance criteria, you can also discover that the story can be broken into more stories. I tend to favour the team choosing to split stories into the preferred granularity, but encourage smaller stories to keep the flow. Using Gherkin acceptance criteria, you can split stories where the acceptance splits occur, for instance in the above, the separate ‘Given’ statements could be stories or in some cases the ‘And’.
Some examples of User Stories which require more work
Example 1 :
As A User
I Want To read the sports news
The term “User” is ambiguous and there is no clear value identified which would usually be captured by the “So That”. The “Sports News” is not clear and appears to be very high level, this could be broken down into many levels. What sports news? Is this a registered football fan? Is this the most recent sports news? and so on…
Example 2 :
As A First Year Student
I Want To submit my english assignment from within my english language class
So That I can meet my homework deadline
Given that I am a user
When I submit my coursework
Then it should submit to the system
The acceptance criteria doesn’t present a clear path to validate or meet the story conditions. What steps need to be achieved to satisfy the story ? Could someone pick this up and understand what needs to be implemented or has the ability to follow the steps to test it? The Acceptance criteria needs to be broken down much further. This story could at an epic level and broken down much further and into many stories.