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:

  1. Introduction
  2. I for Independent
  3. N for Negotiable
  4. V for Valuable or Vertical
  5. E for Estimable
  6. S for Small
  7. T for Testable
  8. Summary


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.

Creating the best User Story with INVEST

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.


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.


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.

user story

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:

  1. Independent of other User Stories. So that it can be modified or removed from the Product Backlog if the need arises.
  2. Negotiable. It should specify what to do leaving the choice of how to do it to the Developers.
  3. 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.
  4. Estimable, meaning having a definable size and completion criterion.
  5. Small enough to be completed in one Sprint.
  6. 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 | 20. INVEST - Creating the best User Story caroline becker avatar 1background

Author: Caroline Becker

As a Project Manager, Caroline is an expert in finding new methods to design the best workflows and optimize processes. Her organizational skills and ability to work under time pressure make her the best person to turn complicated projects into reality.

Scrum Guide:

  1. Glossary of basic terms, roles and notions
  2. What is Scrum?
  3. Scrum values
  4. How to implement Scrum in your company?
  5. Scrum Team - what is it and how does it work?
  6. Who is a Product Owner?
  7. The most common mistakes of Product Owner
  8. Who is the Scrum Master?
  9. Characteristics of a good Scrum Master
  10. The most common mistakes of Scrum Master
  11. What statistics and metrics should the Scrum Master track?
  12. Cooperation between Product Owner and Scrum Master
  13. Development Team in Scrum
  14. The most common mistakes of Developers
  15. Scrum artifacts
  16. Scaling Scrum
  17. Sprint Backlog
  18. What is the Product Backlog?
  19. What are User Stories?
  20. Creating the best User Story with INVEST
  21. The most common User Story mistakes
  22. User Story Acceptance Criteria
  23. Estimation and Story Points in Scrum
  24. Planning Poker
  25. Team Estimation Game
  26. Defining Increment
  27. Scrum events
  28. What is Sprint in Scrum?
  29. Scrum Team Commitments - Product Goal, Sprint Goal and Definition of Completion
  30. What is a Burndown Chart?
  31. How to create and interpret a burndown chart?
  32. Advantages and disadvantages of the burndown chart
  33. Kanban boards in Scrum and Scrumban
  34. Velocity in Scrum - Speed of the Development Team
  35. Daily Scrum
  36. Sprint Planning
  37. Sprint Review
  38. What is a Sprint Retrospective?
  39. Common mistakes during a Sprint Retrospective
  40. Product Backlog nurturing