“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.
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:
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:
INVESTing in good user stories is a worthy endeavor!
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:
Different techniques help in defining the users of a system:
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:
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:
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.
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.