In this article, we will see how to make a good user story to optimize the functional part. If the basis of a good user story is often understood, it is often the source of a lot of problems and misunderstandings.
Simple definition of user stories
A user story is a functional query based on one or more key users of the product that will add business value to the product. It will be written in a natural language understood by all the actors of the project or related to it.
For user stories, where to start?
Having defined his personas
Before even writing your user stories, it is important to understand that it’s essential to have upstream personas (our typical users).
See article : Write well a persona in agile project
User journey and story-mapping
From these personas, you can even help you with a customer journey and a story mapping to have a better vision to write your user stories.
See the articles to learn more about these practices:
What’s a customer journey ?
Story mapping, a clear understanding of its creation
From these elements, you normally have a good preparation to create quality user stories.
From well-defined requests
It is important to start from SMART requests in order to have a good foundation for writing our user stories. If we generally write our user stories from the story mapping at the beginning of the project, it is also advisable to start from requests that respect the 5 rules of the SMART.
Article : Create the user-stories from SMART request!
What make a good user story?
Now that we have all the basics to make good user stories, let’s see how we define what a good user story is.
The title (or summary) of the user story
The basis of the user story is to begin by describing a functional request from a key user (a persona) while writing with a natural language that allows anyone to understand the application:
classic functional request: “the customer must be able to add a product in his cart to buy it”
the title of the user story: “As a customer, I want to be able to add a product to my cart so that I can buy it”.
In fact, we follow a strict format so that all user stories follow the same rules; here is the format to follow:
As a <persona>, I want <goal/desire> so that <benefit>
If the conditions of use are different, we often have a backlog complicated to re-read; it is much easier and more pleasant to work with a minimum of rigor mixed with a minimum of flexibility.
Other existing practices
If the practice provided above is the most popular, there are other user story formats like those we will see right away. If one seems more suited to your needs, do not hesitate to use one of these slightly different formats.
Goal is no longer required
Mike Cohn suggested that the “so that [goal]” part is optional because in some cases the explanation seemed to make the sentence more complex than to really add value.
Make the injection feature
Chris Matt purposes user stories with feature injection that allows you to put the desired value first. It’s an interesting concept to know.
In order to <receive benefit> as a <role>, I want <goal/desire>
Base on the Five Ws
A little known technique that also brings some interesting elements is the user story based on the five Ws (what, who, where, when, why).
As <who> <when> <where>, I <what> because <why>.
I am not particularly fond of this method because I find it a bit too long; however, if you can use it if it seems more adequate for you.
Persona or role
If the use of the persona has become popular with the template proposed by Rachel Davies, you could also use the roles of these personas to do it.
It is not uncommon to see someone use the role of the persona rather than the name of the persona itself. I would say that it has become the most popular case in the world.
For example, if my persona is: “Rachelle, 41 years old client”, we prefer use “As a customer, I wish to be able to add a product in my cart so that I’m able to buy it”.
If you prefer to put the name of the persona, you would imperatively display your personae in your visual management. But for users of software such as Jira, they will have to get used to the personae.
Based on the action
Capital One in 2004 preferred to use “action with the system” instead of “wish” but it remains a subtlety.
As a <persona>, I can <action> so that <benefit>
Here is an example of this subtlety compared to the example of user story that we have been using since the beginning of this article:
Classic: “As a customer, I want to be able to add a product to my shopping cart so that I can buy it”.
Based on the action: “As a customer, I can click on the ‘add to cart’ button on the product page to buy it”.
As you can see it’s subtle but some people prefer to work on the action compared to the wish of the user.
The general content of our user stories
For starters, each project will have its own way of creating user stories. The most important thing is to define the best format for the entire team.
You must understand that a user story is not just a “As [persona], I wish [wish] …”; this is the formatted summary that allows to have a quick view of the application but it must obviously be detailed so that it fully meets the needs of developers to be able to achieve without risk of deviating from the expressed need.
The agility is not allergic to documentation, but just that each user story must contain the minimum to be developable with maximum functional quality and we will make any other documentation after development (technical doc, user doc …). In the agile world, we just refuse to have 300 pages of documentation before that we develop the product. I let you see the principles of agility to better understand why.
User stories: Existing format
To help you, you can look at existing formats that are quite effective. Here is an example that I proposed that is very interesting:
Article : A very effective user-story format: the story A4
Do not hesitate the first time to use this type of existing format and adapt it. The first time that you start a project, it’s never easy to define a concrete user-story format.
To define the ideal user story format for the whole team, I advise you to make the definition of done (and ready) workshop ; we will define the different quality criteria including the mandatory content of each user story.
Article : Definition of Done (DOD)
For example a user story may contain: a description, acceptance criteria, acceptance tests, a simple summary, management rules. The team will define the format that seems ideal for them to work well. There are no good answers on this subject; the best user story format is the one that best fits the team at the moment.
Quality criteria to create my user stories?
Indeed, there are more and more criteria that define the quality expected by a user story. Today the best known is “INVEST” concept that is sometimes misunderstood especially the part I (Independent). I let you go see the article that talk about it:
Article : What’s an INVEST user story?
By respecting all these rules you should be stalled for the creation of user stories.
Example of how to create user stories
What better than a concrete example to understand?
I created a persona in a previous article representing a customer of an ecommerce site (example that I love because it is easy to understand for everyone).
From this persona, I had just created a customer journey of my client on my ecommerce site:
I will use my software (Jira for example) to create my persona based on the A4 story format:
Title: “add a product to my cart”
Type: user story
Description:
As a customer,
I wish to add a product to my cart
so that I buy it
Business rules:
The “add to cart” button on the product page appears if there is a product in public stock. (merchant stock – reserved stock)
When I add a product to the cart, the customer arrives on the shopping cart page
If I add a product to the cart, it’s reserved for 1h
When I add the product to the cart and I already have this product in the cart, we add +1 to the quantity.
Acceptance tests:
Scenario: Given that I'm on my cart And that I have a product of id "1234" in quantity "1" And that the remaining public stock on this product is "0" And I have this product in quantity "0" in my cart When I want to click on the add to cart button Then nothing happens
Scenario: Given that I'm on my cart And that I have a product of id "1234" in quantity "1" And that the remaining public stock on this product is "1" And I have this product in quantity "0" in my cart When I want to click on the add to cart button Then I arrive on the cart page And I have 1 quantity of this product in my cart.
Scenario: Given that I'm on my cart And that I have a product of id "1234" in quantity "1" And that the remaining public stock on this product is "1" And I have this product in quantity "1 'in my cart When I want to click on the add to cart button Then I arrive on the cart page And I have "2 'quantity of this product in my cart.
Conclusion user stories
Now that you understand how to create your user stories in a classic format, you are ready to create a complete backlog. The proposed format is a classic but do not hesitate to adapt it according to the needs of your teams.
Useful link : agile framing
1 Trackback / Pingback