The INVEST Model for Writing Great User Stories | David Tzemach

The INVEST acronym was created by Bill Wake. It was used as a mnemonic for the characteristics of a high quality product backlog item (PBI) commonly used in Agile frameworks such as Scrum, XP or Kanban. The INVEST acronym represents six core criteria for writing user stories and assessing their quality.

The INVEST acronym broken down:

  • I - Independent

  • N - Negotiable

  • V - Valuable

  • E - Estimable

  • S - Small

  • T - Testable

Let us examine each of them more closely:

I - The user story has no dependency on other stories

From an engineering perspective, Stories are easier to work with if they are independent. This is the exact reason why it’s important to ensure stories are as independent as possible. Stories created without dependencies make it easier for teams to plan, estimate and prioritize them more effectively.

Nevertheless, requirements and specifications can be changed. User stories marked with the highest priority can suddenly become less relevant for upcoming sprints. To allow the PO and the team to be adaptable to these changes, we should build our user stories in a way that reduces dependencies between user stories and make trade-offs as needed.

N - Negotiable so it can be changed over time

A good user story is negotiable and not a strict contract. This is driven from the simple format of the user story that captures the essence of what is desired, not the details. The details are added as part of a productive negotiation between the Product Owner and the development team itself.

V - Deliver real value to the customer

If a user story does not have real value to the user (either a customer or internal stakeholder) it should not be done. Update the product backlog often. To ensure the team always delivers the highest business value first.

E - The team can estimate it

A good story can be estimated. We don’t need to make a precise estimation, just enough to help the Product Owner prioritize it in the product backlog and for the team to get a rough idea of how much time it will take to deliver.

S - Small enough to fit into a sprint

In Agile, we aim to deliver an incremental release of the product in a timeframe that does not exceed four weeks (most teams will use two weeks). Therefore, we must create stories that can fit within the allocated time frame.

To make sure that the team can deliver stories in time and guarantee they have a real chance to meet their commitments, the stories should be small enough to be completed in a single sprint.

In my teams, there is a rule-of-thumb that the acceptance criteria must not exceed five requirements. If they do, then the story needs to be broken down into smaller parts. Remember, user stories with a smaller scope will allow the team more comfort within a sprint. They also allow them to gain early feedback from users, which ultimately reduces risk and ensures the team deliver the right product.

T - It can be tested

A story that involves any programming activities must also be tested to confirm it’s "Done". Remember, you cannot develop what you cannot test, and if you cannot test it then you will never be able to mark it as "Done".

The INVEST model is a great way to determine the quality of a user story. However, from my perspective, a great story should serve other aspects that contribute to the team and the process itself. For example:

  • Everyone can understand it – It's simple, a great story will be one that both the Scrum team and the customer can understand and explain its purpose, goal and what value it adds. In my teams, I set a mandatory rule that a user story cannot be added to the backlog unless both the Scrum development team (technical stories) and the Product Owner (functional stories) confirm that they understand its purpose.

  • It leads to healthy discussion – A good user story increases the discussion between team members and reduces the need for detailed documentation. In other words, team members will focus on how to accomplish the story and not waste their time on writing every little detail.

  • Reduce wasted time and effort – When you have a well-written story, the team can start implementation without wasting precious time. A partial story or a story that isn't written well will delay starting the story or cause difficulties during implementation.