INVEST is a method for creating good User Stories. It allows checking if they have properly formulated content and if they relate to the business value of the Product. And also, whether their size and usability have been chosen properly.
Creating the best User Story with INVEST – table of contents:
- Introduction
- I for Independent
- N for Negotiable
- V for Valuable or Vertical
- E for Estimable
- S for Small
- T for Testable
- Summary
Introduction
INVEST is an acronym created by Bill Wake in 2003. Each letter of it stands for the beginning of a word that characterizes a good User Story. According to the INVEST principle, every User Story should be:
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable
We wrote more about what User Story is in a separate article. Here, we will only mention that it is a concise description of a new Product functionality written in accessible language.
I for Independent
The first feature of a good User Story is its independence. It means that its description and characteristics should be understandable without reference to other User Stories. But most of all, its realization shouldn’t correlate with other User Stories. Of course, it will not be full independence. You can’t divide Product creation into completely separate modules. However, it is crucial to remember about keeping User Stories as independent as possible. Thanks to that, even if one of them does not enter the implementation phase or is significantly modified, the remaining one will not have to be modified. As a rule, User Story should constitute a separate and coherent whole.
N for Negotiable
User Story should be negotiable. This means that it sets the Goal, not the way to get there.
In other words, it defines an expected feature of the Product, not a technical solution to implement.
User Story negotiation takes place between the Product Owner and the Development Team. The Product Owner proposes the implementation of certain functionality of the Product, i.e. says “What” to do. The Developers are responsible for answering the “How” question. That is, negotiating specific ways of solving the problem presented in the User Story.
V for Valuable or Vertical
In the acronym INVEST, the letter V stands for two qualities:
- Valuable
- Vertical
Both reveal key characteristics of a good User Story. Therefore, we decided to explain what each of them means.
Valuable
A valuable User Story justifies the business purpose of the modification. In other words, it accurately answers the question of why to introduce the modification be introduced and why it is important from the stakeholders’ point of view.
Vertical
The second feature; Vertical derives from the Agile methodology. The vertical User Story contains a new feature of the Product visible to the User. That is, it does not focus on horizontal “performance improvement” in a selected layer of the Product. On the contrary, it adds another “layer” to it.
In other words, User Story describes how to modify the overall operation of a Product by answering the question of What exactly to improve? It also means that each functionality of the Product builds on existing solutions.
E for Estimable
A good User Story should be estimable. This means that it must clearly define the scope of modifications to make to the product for the User Story to be considered complete. This allows the Development Team to determine the time and effort required to complete it.
The scope and difficulty of a task are usually estimated in units called Story Points. They are relative. And each Development Team works out the Story Point value in practice based on previous experience.
In separate articles, we’ve covered more about Development Team Velocity and how to measure it.
S for Small
User Story accepted for realization by the Development Team has to be concise. That is, it should be no longer than one Sprint. If Developers discover during Sprint Planning that the User Story proposed by the Product Owner is too long, they should split it into possibly independent parts.
T for Testable
The last letter of the acronym INVEST stands for testable. It means that the Product modification described in the User Story must hold water and be verifiable. In other words, it should be possible to verify whether the solution implemented by Developers delivered the assumed value to a specific Stakeholder.
Creating the best User Story – summary
INVEST is an acronym that describes a well-written User Story. It should be:
- Independent of other User Stories. So that it can be modified or removed from the Product Backlog if the need arises.
- Negotiable. It should specify what to do leaving the choice of how to do it to the Developers.
- Valuable, i.e. justifying the business sense of modifying the Product. Or Vertical, i.e. presenting a new feature of the Product visible to the User.
- Estimable, meaning having a definable size and completion criterion.
- Small enough to be completed in one Sprint.
- Testable so that it can be determined with certainty that it has been implemented.
If you like our content, join our busy bees community on Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Scrum Guide:
- Glossary of basic terms, roles and notions
- What is Scrum?
- Scrum values
- How to implement Scrum in your company?
- Scrum Team - what is it and how does it work?
- Who is a Product Owner?
- The most common mistakes of Product Owner
- Who is the Scrum Master?
- Characteristics of a good Scrum Master
- The most common mistakes of Scrum Master
- What statistics and metrics should the Scrum Master track?
- Cooperation between Product Owner and Scrum Master
- Development Team in Scrum
- The most common mistakes of Developers
- Scrum artifacts
- Scaling Scrum
- Sprint Backlog
- What is the Product Backlog?
- What are User Stories?
- Creating the best User Story with INVEST
- The most common User Story mistakes
- User Story Acceptance Criteria
- Estimation and Story Points in Scrum
- Planning Poker
- Team Estimation Game
- Defining Increment
- Scrum events
- What is Sprint in Scrum?
- Scrum Team Commitments - Product Goal, Sprint Goal and Definition of Completion
- What is a Burndown Chart?
- How to create and interpret a burndown chart?
- Advantages and disadvantages of the burndown chart
- Kanban boards in Scrum and Scrumban
- Velocity in Scrum - Speed of the Development Team
- Daily Scrum
- Sprint Planning
- Sprint Review
- What is a Sprint Retrospective?
- Common mistakes during a Sprint Retrospective
- Product Backlog nurturing