The INVEST Model for Writing Great User Stories | David Tzemach
Updated: Mar 3, 2022
Bill Wake created the INVEST acronym. 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 is 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 crucial 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 adapt to these changes, we should build our user stories to reduce 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 by 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.
V - Deliver real value to the customer
It should not be done if a user story does not have real value to the user (either a customer or internal stakeholder). 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 product release in a timeframe that does not exceed four weeks (most teams will use two weeks). Therefore, we must create stories that fit within the allocated time frame.
To ensure 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.
My teams have 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 will enable 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, 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. I set a mandatory rule in my groups 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 debate among team members and reduces the need for detailed documentation. In other words, team members will focus on accomplishing the story and not waste their time 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 execution.