“User Stories are short and simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.” (Mike Cohn)
Creating users stories is a very common practice in Agile software development. They were first coined in 1998 by Alistair Cockburn (one of the great minds who signed the Agile Manifesto). In his own words, “A user story is a promise for a conversation.”.
The following year, Kent Beck, also one of the signatories of the Agile manifesto, introduced the idea in Extreme Programming (XP).
Understanding the purpose and usage of user stories is essential to any Agile practitioner. They reflect the values of the Agile Manifesto. Especially the values “people & interactions over processes & tools” and “customer collaboration over contract negotiation”.
So, what makes up a good user story? It’s not rocket science, but there is a typical template you should use to ensure it’s useful and maintains consistency.
As a < type of user >, I want < some goal > so that < some reason >.
Example: As the HR manager, I want a screening quiz so that I can better understand whether or not I want to send possible recruits to the functional manager.
Much more than a sentence
In 2001, Ron Jeffries — who collaborated with Kent Beck on XP — proposed three incremental steps to keep in mind when creating a good user story, colloquially called the 3Cs:
- Card: This is the tangible part of the exercise. Simply write the user story on a card.
- Conversation: In his book User Story Mapping, Jeff Patton says: “User stories get their name from how they should be used, not what should be written”. That’s to say, you can capture more important details and refine the overall story by having conversations about it with others (developers, users, stakeholders, etc.).
- Confirmation: A user story needs to include information on how to confirm it’s finished. This info should be described in the acceptance criteria section of the user story, typically at the back of the card.
After completing these three steps, the team should be able to implement the story. But how do we know what we’ve created will be useful? A good practice to ensure quality is to follow the INVEST acronym:
- Independent: Implement in any order, no overlap in primary concepts.
- Negotiable: Possibly more or less of a feature.
- Valuable: Story needs to be beneficial to the customer.
- Estimable: Understood well enough to estimate the effort and complexity at the level required.
- Small: If too large, scope, deliverability, and testability risks will be incurred. The general acceptance is that the story should be small enough to fit in less than a sprint.
- Testable: Must have a verifiable definition of done — executable requirements are a best practice.
INVESTing in good user stories is a worthy endeavor!
A step-by-step guide and helpful practices
1/ Focus the user’s vision around three angles: role, need, and business value
A user story needs to address the user point of view, not the system point of view, or any other. To help, you can try answering the following questions:
- Who’s asking for the feature, or who is benefiting from the feature? (role)
- What is requested? (need)
- What value is generated from developing the feature? (business value)
Different techniques help in defining the users of a system:
- User profile: to define the responsibilities and tasks
- User role: to describe context, characteristics and criteria
- Persona: to define a typical user, a fictional representation of the targeted users
2/ Identify the personas and user roles
These personas and user roles will be used throughout product development and referred to in user stories.
3/ Define customer journeys and story maps for a global vision of the product
Customer journeys enable us to understand the whole flow and process you want to address in your product for your customers. A story map is also very useful after identifying the customer journey, to further detail your product and prioritise the features you’ll develop. It’s also a great way to convey the vision of the product. For more insight on this subject, check out Jeff Patton’s book User Story Mapping.
Check out one of a example of a user story map below…
4/ Conversations to improve and further detail a user story
This step is all about having conversations with the different people involved in the product, allowing you to:
- Get a better understanding of the customer/user needs
- Break down the user story if necessary (remember the S in INVEST)
- Define acceptance criteria that allow you to check that the user story is working as intended
- Estimate the user story
Conversations are indeed at the heart of user stories. Without them, they’re meaningless. In the words of Jeff Patton, “good documents are like vacation photos.” Makes sense! Photos look great, but they don’t really tell the whole story. And if you haven’t been part of the conversation, you won’t be able to fully grasp it.
This also goes for any document you share. Writing is always subject to interpretation, even when you try to put as much detail as you can in a document. Just look at how law practitioners argue on interpreting the law!
So don’t rely on any one document to fully convey a message, but do make sure the people who have a need and the people who will fulfill that need engage in a conversation. The document (i.e. the user story) is simply to remember the conversation, the same way a picture will help you remember the events before and after the picture was taken.
5/ Confirm the User Story with acceptance criteria
As mentioned, you need to define acceptance criteria so that the story can be checked. If all acceptance criteria are not filled, the story cannot be considered ‘done’. There is no ‘half-done’ user story, it’s either done or it’s not.
To define acceptance criteria, a useful practice is using the format Given/When/Then.
< Given > some context < Given > some action is carried out < Then > a particular set of observable consequences should be obtained.
An example user story would be, “as a customer, I want to withdraw money at an ATM to avoid long queues in agencies”.
To find an acceptance criteria, we can ask the following questions:
- What do we do if there is not enough money in the account?
- When should a withdrawal be refused?
Resulting acceptance criteria could be:Given the customer has input an amount greater than his account balance, when he/she confirms the amount then the following message appears: “Insufficient funds for the amount selected. Your current balance is: xxx” and the customer is redirected to the select amount screen.
Where possible, the acceptance criteria should be expressed as concrete, executable customer tests.
TL;DR
Users stories are useful tools for expressing user needs for a product. They should encourage simplicity, and convey the user’s point of view. Remember to clarify first and foremost product vision, user roles and personas; involve the customer in the writing process through face-to-face conversations, and respect the INVEST rules. Follow these tips, and you can’t go wrong.
