Writing User Stories with the INVEST Model

Blog | Practicality through serving others

The INVEST model is a tool to help software development teams create good user stories. These stories should be:

  • Independent (I): Able to be worked on individually, without needing to depend on others to be completed.
  • Negotiable (N): Flexible and able to adjust to changes in project requirements.
  • Valuable (V): Useful and adding value to the project.
  • Estimable (E): Specific enough to be able to estimate the time needed for their development.
  • Small (S): Small enough for developers to complete in a short period of time.
  • Testable (T): Specific enough for developers to test that the requirements have been successfully met.

These characteristics help teams create user stories that are easy to understand and develop.

User Story structure

A useful way to structure user stories is as follows:

  • Title
  • Description
  • Acceptance Criteria
  • Subsequent Discussions

Now, let’s develop each part of a user story:

  • Title
    • The title of a user story follows the following formula:
      • AS <role>
      • I WANT <goal>
      • SO THAT <motivation>
    • The title of a user story should be specific enough for readers to understand what it is about, reflecting the intention and goal the user is trying to achieve. It should provide the necessary information for the development team, design, and product owner to know what the story is about and what problems it is trying to solve.
    • Example of user story title: “AS a user, I WANT to be able to create an account to log in, SO THAT I can access all the features of the site”.


  • Structure
    • Context: The context describes the current situation, existing problems, and user needs.
    • Links to mockups or designs: Prototypes are important to provide a clear vision of how the user story will be applied to the user interface.
    • Limitations: Limitations should be set to make sure the development team has a better understanding of the user story requirements.
  • Example of user story description: “Due to the user not being able to access the site, they need to create an account to access all the features of the site. Users should be able to log in with their email address and password. The design of the user interface can be found at the following link: [Link to mockup].”

Acceptance Criteria

  • Structure
    • Atomicity: Acceptance criteria should be defined in atomic terms to ensure the development team knows exactly what is expected to be done.
    • Non-Ambiguous: Acceptance criteria should not be ambiguous to avoid confusion.
    • Verifiable: Acceptance criteria should be verifiable to make sure the results are as expected.
    • Complete: Acceptance criteria should be complete to ensure all requirements are covered.
  • Example of User Story Acceptance Criteria:
    • The user can successfully create an account.
    • The user can successfully log in.
    • The user can successfully view the site content.

Subsequent Discussions

  • Between the engineering team, product owner, and design. These discussions are important to ensure the team has a clear understanding of what is expected to be achieved with the user story.
  • Example: The engineering team discussed with the product owner and design about the limitations that should be set to make sure the user could not access the site content without having a user account.


In conclusion, the INVEST model is a useful tool to help teams write good user stories that are independent, valuable, estimable, small, and testable. User stories should follow a structure with a title, description, acceptance criteria, and subsequent discussions. These elements help software development teams to clearly communicate and understand the requirements of a user story, ensuring that the product meets the user’s needs.