But beware, a user story can quickly be badly written. To be truly effective, they must follow certain rules, which can be found in the acronym INVEST, coined by Bill Wake.
So in this article, we're going to break it all down and show you how this principle can make your user stories even better and give your project a real boost.
So, are you ready to take your user stories to the next level?
What is a “user story”?
/*! elementor - v3.13.3 - 28-05-2023 */
.elementor-widget-image{text-align:center}.elementor-widget-image a{display:inline-block}.elementor-widget-image a img[src$=”.svg”]{width:48px}.elementor-widget-image img{vertical-align:middle;display:inline-block}
A user story, also known as a backlog item, is a medium used in software development that captures a description of a desired functionality from the point of view of the end user.
It helps development teams to understand user needs and desires by formalising them in concrete terms, and to design solutions that meet these expectations.
A user story is always introduced as follows:
“As a [type of user(s)],
I want to [some functionality].
In order to [a certain profit]”.
For example, a user story for an e-commerce application will present the user's needs as follows:
“As a client, I want be able to filter products by category in order to make it easier to find the products I'm looking for”.”
Simple and effective, isn't it?
Once the requirement has been expressed in this way, the functional analyst or business analyst will complete the User Story by adding functional rules and constraints that the development that is to be carried out to meet this requirement must respect.
A user story is a way of encouraging communication. It allows developers to put themselves in the shoes of users when creating software.
This is a central element of many Agile development methodologies, such as Scrum, and Extreme Programming (XP).
What does INVEST mean?
The acronym INVEST, which is used to describe the characteristics of a good user story in an Agile method. This helps to add value to the creation of the project.
INVEST is an acronym that stands for :
I - Independent
N - Negotiable
V - Valuable
E - Estimable
S - Size appropriately
T - Testable
Here's a quick overview to help you understand the importance and scope of each of these elements:
Independent
Each user story must be independent, i.e. it must not depend on another user story to be of value.
This makes planning easier, because the stories must be able to be developed in any order. A developer doesn't have to wait for another developer to develop a new US.
Negotiable (“negotiable”)
A user story is not a contract, but rather an invitation to a conversation. It must be flexible and open to discussion and adaptation. The Functional Analyst or Product Owner always presents each US to the developers, who offer their ideas for simplifying and improving the User Story to meet the need as simply as possible. Added value is always at the heart of the conversation.
Valuable
Each user story must bring value to the end user or customer. If this is not the case, you need to ask yourself whether the story is necessary.
Each US must maximise the value it brings to the user. It is this notion of value that will enable the Product Owner to decide on the scheduling of the User Stories in the backlog, which is the listing of USs by development priority on which the entire Agile team is based.
Estimable
The development team must be able to estimate the “size” of a user story, generally in terms of the time or resources required to implement it.
If a user story cannot be estimated, this may mean that it is too large and needs to be broken down into several smaller stories.
In the event of separation of the US, the greatest difficulty is always to maintain the independent nature of the user stories. It is the role of the Product Owner to make the best choice. Often, reducing the size of the US is more important, to the detriment of the independence of the USs from each other.
Small (“small enough”)
Agile Scrum developments are punctuated by Sprint periods lasting a few weeks, during which the development and testing team must deliver a predefined number of user stories.
This is why 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.
Testable
It must be possible to test a user story to check that it has been correctly implemented. If a story is not testable, this may indicate that it is not sufficiently clear or specific.
Origin
The acronym INVEST was created by Bill Wake, a software development coach, as a way of recalling the characteristics of a good user story in Agile development. He first introduced the acronym in a 2003 article entitled “INVEST in Good Stories, and SMART Tasks“.
The Agile method itself was first formalised 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), became common practice in software development shortly afterwards.
Conclusion
A well-constructed user story offers valuable insight into the needs and desires of the end user.
By using INVEST, you can ensure that your user stories are independent, negotiable, a source of value for the user, estimable, of appropriate size and testable.
Find out more about agile project development, don't hesitate to read our previous article.
If you want to develop a project with skilled developers, you should know that iterates uses this method and can help you.
