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.

It’s a central element of many Agile development methodologies, such as Scrum and Extreme Programming (XP).

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:

Independent

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.

Negotiable

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.

Valuable

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.

Estimable

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.

Small

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.

Testable

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.

Origin

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.