The perfect user story.
Quite often I find myself struggling and spending so much time to write the perfect user story. I would prefer to use that time to have customer interviews or prepare some discovery events or story mapping sessions. I have to note that the Scrum Guide doesn’t mention the term ‘User Story’. Instead the term used is Product Backlog Item — PBI. However, User Story is a very popular term, used by many Scrum Teams.
Mike Cohn has a great definition: user stories are short, 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. They typically follow a simple template:
As a < type of user >, I want < some goal> so that < some reason>.
- type of user = WHO
- some goal=WHAT
- some reason=WHY
Easy right? Well not quite..
Below some tips to have in mind when creating a user story.
1. WHO is the user? WHO you are building this for?
It’s important to know who are the real users of the feature you are creating. In other words, you should define the right personas of your system. These are people that ideally will tell the story to the Scrum team. Once you define these you can start with the first part of the template, examples of users are: online banking customers, marketing managers, hotel guests, flight bookers, amazon prime members.
2. WHAT is the goal? WHAT are we building?
Now that you know for who you are writing the user story let’s see what the user will do. The WHAT is about the action that the user takes once he/she lands on the software the team is developing. For example the second part of the templates may include “As a user, I want to: pay a bill, check balance account, place an order, sort results by date, book a flight, search for honeymoon resort etc. There are endless things that the user can do. For that reason is important to know why the team is building a specific feature or functionality.
3. WHY is this important for the user? WHY are we building it?
It is important to understand WHY a specific feature is needed. The answer to this question shows what value will the user story add to the user or customer. Examples of the third part of the template can be “so that I can: check my monthly expenses, find the latest information, book the best deal etc”. It is important for the development team to know WHY they are solving this for the user so they can determine HOW they need to proceed.
4. Who and when can write a user story?
Anyone can write user stories at anytime!
I mean really anyone, from product owners to sales representatives, even the user himself can write one. However, product owner’s responsibility to go through all of them, understand them, group them, ask for more information when it is necessary, delete the ones that are not aligned with the product vision and of course the most important task PRIORITIZE the user stories.
5. INVEST (mnemonic)
The INVEST mnemonic for agile software projects was created by Bill Wake in his book Extreme Programming Explored as a reminder of the characteristics of a good quality Product Backlog Item (user story).
- Independent — A user story should be self-contained, in a way that there is no inherent dependency on another story.
- Negotiable — The user stories are not explicit contracts and should leave space for discussion.
- Valuable — The user story must deliver value to the stakeholders.
- Estimable — You must always be able to estimate the size of a user story.
- Small — The user stories should not be so big as to become impossible to plan/task/prioritize within a level of accuracy.
- Testable — The user stories must provide the necessary information to make test development possible.
6. How much details should you add?
I have seen user stories that their description cover full A4 page!
I recently read a great article about the product backlog items. There was the below line that caught my attention.
A great Product Backlog Item starts a conversation. The goal of this conversation is to establish common understanding. — Maarten Dalmijn
If you think about it, no matter how perfect or how much details you add in a user story it is useless if the team that develops the item doesn’t understand it or challenge it. In my opinion, a user story should be ready to be implement when the team achieves a common understanding. Many things can come up during the development phase and collaboration it’s important to solve any impediments or assumptions. Don’t get me wrong, that doesn’t mean you should write poor user stories without acceptance criteria etc just don’t get obsessed about a perfect detailed user story.
7. Οne-size-fits-all approach will not work!
Let’s be pragmatic, it’s great to follow a template but what happens when you struggle to make the story fit the template?
Take for example small improvements. You go to the Sprint Review and you are lucky enough to have your users next you. Some users say that the info box text is too small to read. So you go back to your desk and you write something like “As a user, I want the info box text to be bigger, so I can read it.”
You have several small stories like this. It seems you are repeating yourself. Why not start writing Improvement stories with a simple template like the below?
We have<current situation>, we want to have<desired situation>.
In this case, the above user story will be: “The current info box is 10px, we want it to be 15px”. Simple!
If you are trying to explain something that does not fit the template just put it in simple words!
8. … what about technical stories?
How many times you have seen a story like this:
As a developer, I want a database, so that the application can store data.
or like this:
As a developer, I want to be notified when application performance falls below a threshold.
There many opinions on how to express this kind of work. There are opinions to define Devops personas and write user stories accordingly. There are other opinions that say these are not user stories and these kind of work should be expressed in tasks.
My opinion is don’t waste time on writing the user story! If there is work to be done, for example if you need to update a DB version, then just write a text that describes exactly what you need to do, for instance “ Update to the latest MySQL 8.0.12”. Spend your time refining the work that needs to be done in order to gain a common understanding than trying to fit a template.
Conclusion
I believe a good structure can help the Scrum team to have a common understanding. I am in favor of using a template to write a user story. However, if it takes much more time to fit the story to the template then just use alternative templates or just simple words. Use that time to add acceptance criteria and to refine the story with the team to have a common understanding on what needs to be done.
Perhaps a perfect user story is not written, but told. Even a few words on a post-it can mean a lot when a story has been told in person. — Sjoerd Nijland
What are your thoughts? How do you write user stories? I am happy to hear all about it!


