USER STORIES | ALL YOU NEED TO KNOW ABOUT WRITING THEM (GOOD).
World of Digits / Explore
World of Digits / Explore
For sure you’ve already heard of User Stories (or US) whatever your role is in a project (Agile or not). They are no more and no less the heart of the project. When assembled they include the functional and sometimes technical description of the need expressed by the customer (or Trade/Business). They also consist when necessary of the UX/UI vision, the associated development time, and all the tests that will be implemented. Setting up a US can sometimes be tedious.
Many theoretical aspects explain how US should be conceived when expressing a need, how it should be managed and prioritized once it is backlogged. Even if a PO attempts to respect and implement these precepts, the practice and context peculiar to each client can sometimes work against them.
The aim of this article is therefore to share with you the good practices of writing a US, and to compare theory to practice.
The primary goal of a User Story is to functionally and sometimes technically describe a need. As defined, at the time of its writing, this need is already finely cut, unitarily forming US. Put together, they match the need expressed by the Business and matured by all the actors of the project.
Expressed roughly at the start of a project, the need must be functionally and technically refined by all stakeholders. At the end of the line, it can sometimes turn out to be very different from what was expected given the constraints.
It is therefore necessary to proceed by division and to bring out the major themes (called EPICs) as well as to identify an MVP (Minimum Viable Product). This MVP represents the smallest part of the project that can be developed in a minimum of time. It helps to bring real customer value along with quick feedback in order to adjust, refine or recast the initial need.
This work is often done during an Agile ritual called “Story Mapping” which brings together several people around the table. The one who expresses the need, the PO, a representative of the development team, a UX/UI, and the tester.
Thus, this 360 vision makes it possible to provide all the necessary knowledge when defining the need and to anticipate as much as possible any blocking points or non-feasibility.
At the end of the workshop, the PO should have identified his MVP and its EPICs, which will allow him to then be able to imagine his User Stories and to write them down.
All the POs have a common working basis. They start writing a user story via the INVEST method; then follow the life cycle of this within Jira (mainly used management tool).
The INVEST method is the abbreviation of several theoretical rules that will allow you to identify the foundations of a user story. This method respects the following points:
Independent: You have to ensure the US is independent from the other User Stories and it can be implemented at any time.
Negotiable: It has to come from a conversation between the Business, the PO, and the technical team.
Value: The US has to put forward the user need.
Estimable: It has to be assessable technically by the Development team.
Small: The US has to be short enough to be described in 3 lines.
Testable: It should be validated by acceptation tests that will confirm the US functional characteristics.
When writing our first US, we go through them one by one to see if they meet the INVEST principles. Over time, it becomes an automatic process. We keep in mind the foundations when creating the US without questioning whether or not the theory is respected. Below are some examples implemented during our respective missions:
“Wanting to finely cut the functionality leads to a certain dependence between User Stories. Sometimes, I have to complete a user story with a technical story (technical US). The US, therefore, becomes dependent on the technical story.”
– Namel
“The user stories’ estimation is not necessarily done based on customers. It still happens that the US is estimated in man-days rather than in complexity points.”
– Sophia
« Most of the time, the User stories can be tested at the end of the sprint. Still, if the User Stories are dependent on each other, they may be untestable at the end of each development.”
– Namel
A word of advice for you reader; if there is no precise schedule for processing the INVEST points, it is however interesting to start with the VALUE point in order to identify the User Stories with the most User value. A US may be abandoned after its value is assessed.
During the project, the life cycle of a US can be followed on a KANBAN board with the steps below. It should also be taken into account that this way of ordering the columns and the titles of the statuses proposed below may depend on the way your team is organized, the level of agile maturity and your project:
Once the US has been validated by the QA/Recipe team, it can therefore be put into production.
“As a Product Owner, one is responsible for the board proper monitoring. At Crédit du Nord, working on the project to redesign the employee portal, in charge of facilitatating exchanges with the 4 developers and my PPO, we set up a board dedicated to the PO team which includes the following steps: New, design, ready to dev (RTD). Once the US is in the RTD stage, it automatically enters the backlog of a second board dedicated to developers. In the poker planning of each sprint, we get the US on board, so they arrive at the TO DO stage. Their state changes depending on the progress of the sprint.”
– Namel
“My practice for the Gecina client space launch project is completely different from Namel’s experience at Crédit du Nord. Indeed, we only had one board made up of the above steps, but with different terms (for example, instead of “In progress”, the step is called “In dev”) and the exchanges with the 4 developers of the project were not disturbed for all that. The terms of the steps may vary depending on the habits of the company, the goal is to achieve the same result.”
– Sophia
As indicated above, the drafting of the US is done during the design phase.
In addition to the INVEST method, you can use the unique template that will allow you to structure the US. The latter is composed of a title (As (the end user), I want (the action) in order to (the need)) and of acceptance criteria (Since (the user situation) and (the situation complement) when (the action carried out) then (the obtained result)).
At our respective clients (Accor for Sophia, Axens for Namel), we use the template described above when drafting the User Stories. Indeed, having a template forces us to respect the frame and to have homogeneous User Stories. This standardization, therefore, makes it easier for the Development team to understand. On the other hand, for Gecina for Sophia and PSA for Namel, this aspect was relatively respected at the beginning of the sprints. We found that depending on the maturity level of the Development team, we were no longer constrained to use the formulation.
Once the US has been validated by the QA/Recipe team, it can therefore be put into production.
To finish this reading, we offer you a list of best practices that you can use in your daily life.
At Foncia as part of the redesign of the customer space, and at PSA for the implementation of a factory incident handling tool, the title of the US was different from the theoretical standard. We preferred to label them by functionality or user need. Despite respecting the structure of the US when working with the Dev team in sprint planning or backlog grooming on Jira, we realize that all User Stories have the same name. We are therefore forced to go into the details of each US. For example, we put the title “Identification/authentication page” instead of “As a bank customer, I want to authenticate on the customer space in order to view my accounts”.
“The visual is additional help for the Dev team. It will use it to validate the desired behavior. For example, at Accor Hotels, to develop the evolutions of the e-commerce website linked to new commercial offers, the US was not considered to be ready to be developed until it was accompanied by a wireframe.” – Sophia
“Velocity is defined during sprints. I advise you at the start not to embark a lot of User Stories in order to avoid a remainder of unfinished User Stories. Indeed, during my mission at Crédit du Nord for the Biometrics Voice project, we noticed that a left over US can have a negative effect on team motivation and lead to disappointment. It is therefore advisable to take on a reasonable amount of complexity points and to add some of them during the current sprint depending on the Dev team progress. This requires that the User Stories in the backlog be prioritized and in Ready to dev status.” – Namel
“When sizing, it is important to properly divide the User Stories. A tip? You can split a large feature into multiple User Stories. Even if they become dependent on each other. For example, the golden rule was to have no US above 8 points of complexity. If a US was estimated at more than 8, we would divide it into several User Stories.” – Namel
“Do not hesitate to ask for clarification or question the user needs / Business Owners. This will allow you to best meet their expectations. Here is an example; in order to optimize the Barrière Group’s mobile application (hotel sector), I would reformulate their need in my own words. So I could be sure we were on the same page at the end of each workshop.” – Sophie
There are two main skills you need to demonstrate in writing a US; adaptability, and communication with the development team. Indeed, at some of our clients, we had to follow the structure of a US, while at other clients, the acceptance criteria were instead replaced by more complex business rules. Then, the Business Owner would validate these later detailed in a functional specifications document. This document can be used in addition to the User Stories.
Finally, as you’ll have understood it right, the way to approach a US totally depends on the working environment of the client and the Agile maturity of the project team. The advantage of carrying out various assignments is to enrich our working methods and learn from customer contexts. This enrichment helps us consolidate and improve over time our ability to write a “good User Story” and gain expertise in our role as a Product Owner.
Consultants at World Of Digits for about 3 years, Sophia and Namel are also contributors for the French PO Tribe. Tribes at WOD aim to share and learn from others through various workshops and articles they produce.
“I started in the digital world as an e-commerce project manager for the hotel sector of the Barrière Group for 2 years. After a year spent in entrepreneurship, I joined WOD as a consultant Project Manager / Product Owner. I have supported various clients such as Foncia, Accor Hotels or Gecina. I am currently a Digital Business Analyst for Axa on various projects to optimize customer spaces.”
– Sophia
“I first worked as a Project Manager for 2 years at Crédit Agricole before discovering the consulting world. I was then able to complete 5 assignments as a Business Analyst. When I joined WOD, I started at Crédit du Nord as a Proxy Product Owner. Over time, I became Product Owner on the Voice Biometrics project. I now support my client as a Product Owner on four different projects. My progress within my mission testifies to the relationship of trust that we have with our client.“
– Namel
Read this article
Working smarter, not harder, is possible for your developers and designers thanks to the right collaboration tool.
Read this article
Many UX designers are familiar with the problem of a creative block. But how do you make the most of this moment of low?
Read this article
Read this article