If you’re interested in software development, you’ve heard of ‘user stories’ or ‘US’. They are at the heart of the Agile method and are a great way to focus on the end-user’s needs.
But be careful, a user story can quickly be poorly written. To be truly effective, they must follow certain rules, which are found in the acronym INVEST, conceived by Bill Wake.
So in this article, we’re going to break all that down and show you how this principle can make your user stories even better and give a real boost to your project. So, are you ready to take your user stories to the next level?
What is a ‘user story’?
A user story, also known as a backlog item, is a tool used in software development that captures a description of a desired feature from the end-user’s perspective.
It helps development teams understand the needs and desires of the user by formally expressing them, and to design solutions that meet these expectations.
A user story is always introduced as follows:
‘As a [type of user(s)],
I want [a certain feature]
So that [a certain benefit].’
For example, a user story for an e-commerce application would present the user’s need as follows:
‘As a customer, I want to be able to filter products by category so that I can find the products I am looking for more easily.’
Simple and effective, right?
Once the need is expressed in this way, the functional analyst or business analyst will complete the User Story by adding functional rules and constraints that the development must respect to cover this need.
A user story is a way to foster communication. It allows developers to put themselves in the users’ shoes when creating software.
What does INVEST mean?
INVEST is an acronym used to describe the characteristics of a good user story in an Agile method. It brings value to the project creation.
INVEST stands for:
I – Independent
N – Negotiable
V – Valuable
E – Estimable
S – Size appropriately
T – Testable
Let’s take a quick look to understand the importance and scope of each of these elements:
Each user story should be independent, meaning it shouldn’t depend on another user story to be valuable.
This facilitates planning, as stories should be able to be developed in any order. A developer should not have to wait for another developer’s work to develop a new US.
A user story is not a contract, but rather an invitation to a conversation. It should be flexible and open to discussion and adaptation. The Functional Analyst or Product Owner always presents each US to the developers, who propose their ideas to simplify and improve the User Story to meet the need as simply as possible. Added value is always at the center of the conversation.
Each user story must bring value to the end user or the customer. If this is not the case, it is necessary to question whether this story is necessary.
Each US must maximize the value brought to the user. It is this notion of value that allows the Product Owner to decide on the ordering of the User Stories in the backlog, which is the listing of the US by priority of development on which the entire Agile team is based.
The development team must be able to estimate the “size” of a user story, generally in terms of time or resources needed to implement it.
If a user story is not estimable, it may indicate that it is too large and needs to be broken down into several smaller stories.
In case of separation of the US, the biggest difficulty is always to maintain the independent nature of the user stories. It is the role of the Product Owner to arbitrate this choice as best as possible. Often, reducing the size of the US is more important, at the expense of the independence of the US among themselves.
Developments in Agile Scrum methodologies are rhythmic in Sprints of a few weeks, during which the development and test team must deliver a defined quantity of user stories in advance.
Therefore, user stories must be small enough to be completed in one iteration (sprint). If they are too large, they need to be broken down into several smaller stories.
It must be possible to test a user story to verify that it has been implemented correctly. If a story is not testable, it may indicate that it is not sufficiently clear or specific.
The INVEST acronym was created by Bill Wake, a software development coach, as a way to remember the characteristics of a good user story in Agile development. He first presented this acronym in a 2003 article titled “INVEST in Good Stories, and SMART Tasks.”
The Agile method itself was formalized for the first time in 2001, when 17 software developers came together to create the Agile Manifesto, a set of principles designed to improve software development processes.
User stories, as a key element of several Agile methodologies, such as Scrum and Extreme Programming (XP), have become a common practice in software development shortly thereafter.
A well-constructed user story offers a valuable perspective on the needs and desires of the end user.
By using INVEST, you can ensure that your user stories will be independent, negotiable, valuable to the user, estimable, appropriately sized, and testable.
To learn more about project development using the agile method, feel free to read our previous article.
If you are looking to develop a project with competent developers, be aware that Iterates uses this method and can assist you.