The term User Story appeared with eXtreme Programming “XP”, an Agile methodology oriented on the app’s realization aspect. In 1999, Kent Beck, one of the creator of this method, published the principle of the User Stories. For the first time, they used maps to define specific tasks: at the time they help identify functionalities to develop.
Since then, the User Stories were globally adapted in Agile processes. While no one contest their utility in modern project management, the fact remains that writing an useful and reliable User Story can be a real obstacle course. How to be sure that it is enough developed? What benefit your final user gets from it? 🤯
In this article, we answer those questions! You will find here the key steps to pull the best out of your User Story. 👇
What is an User Story?
Let’s begin with the definition. An User Story is a sentence, characterizing one of your product or service’s functionality. It is always written from the user’s point of view!
📢 Your User Story should allow you to determine the added value of your product’s functionality for your client.
Created by the Product Owner, they build the Product Backlog: they define which functionality should be developed throughout the project.
Let’s take an example: imagine I am in charge of the sales of our company’s products. Every day, I use our sales management tool to export raw data (CSV). Then I build a reporting and send it to the management.
As a Sale Manager, I would like to obtain this CSV export every morning in my mailbox. This will prevent me to do the same manipulation every day, which is not a real value to my work.
From this example, the User Story that should be build is :
As a Sales Manager,
I want to receive the sales’ export every morning at 9am in my mailbox,
So that I can spend more time to the analysis of those data (work where my added-value is stronger).
Now, let’s look at the steps to built it!
The key steps to write an User Story
1 – Define your personas
This first step can seem obvious. It is, of course, central to the User Stories’ writing process!
📢 A persona is a fictive character, which represents a part of your product’s final users. While defining your persona, you put yourself at the place of your target, in the objective to understand its needs as well as its issues regarding your product.
Usually, a persona is composed of:
📌 a name, a picture and a detailed profile,
📌 the description of its behaviour and its needs,
📌 a goal.
Define in a clear and accurate way your personas will help you determine the functionalities bringing value to your product ! To help you build those persona, you can use tool like Make My Persona.
2 – Identify the needs
Portray your personas will guide you in the expression of their needs. Those 3 questions can help you to frame your thoughts:
📌 What does my user wants?
📌 Which frustrations does he want to avoid?
📌 Which benefits does he want to find in our product?
📢 Don’t forget: each needs equal a specific User Story!
3 – Write the User Story
This is the core phase: the writing ! Ideally, it is composed of three parts, creating a sentence:
As a [persona]
I want [need]
So that [expected result]
📢 You should use clear and concise words! For example, the term “fast” does not mean the same thing for everyone. It is better to favour accurate and measurable expressions such as “in less than 3 minutes”.
4 – Check the feasibility
Now that your User Story is written, you need to verify its feasibility for your team. For that, you need to ensure that it is possible to execute it:
📌 by one person
📌 in an iteration time.
If not, you will have to divide this User Story until you can respect those two rules!
5 – Check the quality
A lot of tools and methods exist to ensure your User Story’s quality. For example, in Agile Methodologies, the norm is to follow or respect INVEST’s mnemonic. This mnemonic allows to define the elements characterizing your User Story, as well as control its construction!
As written previously, an User Story is equivalent to an unique functionality of your product. It should not depend or require the realization of another one.
Your User Story’s details should not be frozen. This would go against Agile methodologies principles.
Who says unique functionality says added value identified! Each one of your User Stories should contain a profit for your final user.
It is important to be able to evaluate the workload that each User Story represents for your team.
As said, an User Story should be doable in an iteration time.
By testable, you should understand measurable and quantifiable. As explained earlier, using numerous terms rather than non-factual expressions will permit you to test your User Story!
📢 “3 minutes” is a better indicator than “quickly”.
6 – Share your User Story with your team
Once your User Story validated, the last step of the creation process is the talk with your project’s team member! This crucial phase will allow you to test it, and discuss with your team about their utility, as well as the detail of its realization!
📢 An User Story is a sum up of a functionality that will be developed in your product. While debating it with your team, you will detail it, and ensure that it will be feasible for your developers, without deviated from the expressed need!
That’s it, you are done! Your User Story is finalised, and ready to be integrated to your Product Backlog.
Although we presented there the key steps to write your User Story, it seems important to me to remind that it is only ONE way among so many others to write one. Each project will have its own way to create them: the most important is to find the form that suits the most the whole team members!