Writing meaningful user stories with the INVEST principle

Editor’s note: This article was reviewed and updated on 10 September 2024.

In agile software development, user stories enable both planning and execution. To enable planning, user stories serve as containers to express user needs clearly and concisely. To enable execution, user stories are written with business-friendly language to signal technical practitioners to the software components they need to build for a complete solution.

There are many techniques that agile practitioners use to write effective user stories, and in this article, we’ll take a look at one of those techniques — the INVEST principle, a set of guidelines that helps us evaluate a user story’s quality.

According to the INVEST criteria, good user stories are:

• Independent — The story is conceptually separate from, and doesn’t rely on, other user stories
• Negotiable — The story may evolve during the conversation until the team arrives at a balanced solution
• Valuable — The completed story clearly meets an actual user need
• Estimatable — The story is detailed enough that the team can estimate its relative size
• Small — The story can be completed in a short time window without losing value
• Testable — The story can be tested to ensure it passes a clear set of acceptance criteria

Understanding user story attributes

It’s common for teams to struggle with writing user stories, especially for teams that are relatively new to agile software development. Some of the most import attributes of user stories include the following:

• Who it’s for — The target user for the user story (most often expressed as a persona or user type)
• What it seeks to achieve — The goal(s) of the target user
• Why it matters — The reason(s) those user goals are important
• How to know it’s complete — The forms of evidence that show the user story has met expectations

A popular way to write user stories is to start with the following syntax:

As a [role/persona/user type]
I want [goal or action]
So that [desired result from goal/action]

For example, using this syntax, you could write a user story such as the following in an insurance or health care context:

As the primary applicant
I want to enter the passcode I received from my representative
So that I can access my account and ensure my claim information is accurate

One reason the syntax above is popular is that it helps teams remember to address each of the first three bullet points above (who, what, and why). Teams also write acceptance criteria as part of the user story, to make sure it’s clear what “done” means for that user story.

What is the INVEST criteria in agile?

Writing user stories using syntax such as that described above is helpful. Still, there are other considerations that are important for teams to consider when writing user stories. Recognizing the need for a method to help teams avoid common pitfalls in agile software development, Bill Wake first articulated the INVEST principle in an Extreme Programming (XP) article in 2003.

INVEST is an acronym to help teams write high-quality, specific user stories that are independent, negotiable, valuable, estimatable, small, and testable. The INVEST principle in agile, therefore, is the practice or framework to follow when creating these user stories:

Breaking down the INVEST criteria for user stories

Let’s take a closer look at each one of the user story attributes associated with the INVEST principle.

Independent

An independent user story is one that is: 1) conceptually separate from other user stories, and 2) not reliant on the completion of other user stories.

The independent aspect is important because agile teams seek to surface any dependencies that exist and eliminate them whenever possible, and that can’t happen if the user stories depend on one another’s completion.

For example, suppose that a Scrum team is considering working on two user stories — we’ll call them A and B — during the same sprint. Work on story B cannot start until story A is done. If story A does not reach completion until the end of the sprint (or is unfinished), the team has put itself in a position where the likelihood of unfinished work is considerably higher. By doing so, the team has incurred schedule risk.

Negotiable

When a team approaches a user story as negotiable, it means the story is an “invitation to a conversation.” As the team gets more familiar with the story context, additional ideas may emerge, the wording of the story may change, and details may be added.

Agile teams leverage their combined wisdom to arrive at a good enough solution to address a particular user need, where “good enough” strikes a balance between value (meeting a real need), cost (being a reasonably small chunk of work), and complexity (aligning with the existing design/architecture).

Valuable

This one is rather self explanatory. A completed user story has value when it meets an actual customer need.

One of the tenets of the Agile Manifesto is working software over comprehensive documentation, and that statement helps teams remember to keep customer needs top of mind. In much the same way, completion of each user story needs to be realized as actual value delivery, even if it’s a tiny change.

Estimatable

An estimatable user story is one that is understood well enough by team members to be able to determine its relative size. In practice, “relative size” means that given a set of user stories, team members can determine which stories are about the same size. T-shirt sizes such as small, medium, and large often serve as a helpful relative sizing construct.

It’s important to recognize that some teams don’t estimate user stories. Thus, being estimatable is synonymous with being reasonably close to ready to work on without too much additional conversation. On teams that do estimate, it also means they know enough about it to assign a size to it.

Small

The S in INVEST stands for small. A small user story is one that can be completed during a short time window — for example, no more than a few business days.

This is important because teams that consistently work on small user stories are far more likely to finish stories than teams that struggle to keep their stories small.

Testable

A testable user story is one that can be verified to have met the story’s acceptance criteria (also known as “conditions of satisfaction”).

The clearest indication for a team to know that a story is done is for all of its tests to pass. User stories with vague or missing acceptance criteria are much more likely to surface as quality problems when in the hands of a customer.

Applying INVEST in Scrum

When it comes to planning, Scrum follows a predictable cadence. There is a product backlog containing a prioritized list of user stories for a team to work on, and, on a recurring basis, members of the team clarify user stories and choose the ones to work on for the next sprint.

To do this, they focus on stories that are at or near the top of the product backlog (aka backlog refinement) and choose user stories to work on during their next sprint by placing selected stories in the sprint backlog (aka sprint planning).

By applying the INVEST criteria for user stories during backlog refinement and sprint planning, Scrum teams can realize benefits associated with each area of the INVEST principle:

• Independent — Selecting only independent stories reduces or eliminates dependencies, which is especially important in a cross-team context
• Negotiable — By partnering with the product owner and the Scrum master to refine user stories, developers can get a better understanding of the work surface alternative ideas
• Valuable — Asking “is it valuable to do this?” for any user story serves as a key prioritization tool. It also serves as a helpful reminder when refining user stories and making decisions on which stories to include in the sprint backlog
• Estimatable — The Scrum master can be especially helpful to the team by making sure each person’s point of view has been considered when discussing and sizing user stories
• Small — When Scrum teams consistently choose small stories and only select as many stories as they can realistically complete during a sprint, they significantly improve their chances of achieving the sprint goal and reduce risk
• Testable — Consistently articulating clear and concise acceptance criteria helps ensure that the work that a Scrum team does is of consistently high quality and meets user expectations

Note: Teams that are not practicing Scrum can also realize benefits by applying the INVEST principle.

Concepts that complement INVEST criteria in user stories

The INVEST principle aligns nicely with the following concepts:

• The Three Cs
• The DEEP principle

Let’s get into these concepts in more detail.

The Three Cs

The Three Cs is a concept first articulated by the agile practitioner and XP co-creator Ron Jeffries in an article in 2001, where the Cs represent:

• Card — The initial, elemental concept associated with a user story (the shortest form of which is the story’s title)
• Conversation — The dialogue that takes place among team members during team planning sessions or on an ad hoc basis. This leads to better understanding of a user story, often expressed via documentation (where the documentation is most often internal to the user story and can also be external to the user story)
• Confirmation — The point at which team members have a shared understanding of a user story, often formalized via acceptance criteria

The INVEST criteria align especially well with the conversation and confirmation parts of the Three Cs, since team understanding is most likely to be achieved for a user story when each of the six parts of INVEST surfaces during team conversation.

The DEEP principle

The DEEP principle also works well in tandem with the INVEST criteria for user stories. You can apply DEEP to the product backlog as a whole, while you can use INVEST to fully elaborate individual user stories in the product backlog.

Thus for any item in the product backlog, a team can see whether each of the following is true:

• Detailed appropriately — User stories at or near the top of the product backlog are articulated at a level of detail where they are ready for the team to work on with little to no additional conversation, while stories further down the backlog contain less detail
• Estimated — User stories at or near the top of the product backlog have been estimated, or are capable of being estimated, while stories lower in the backlog are likely not understood well enough to be estimated
• Emergent — It is assumed that there is a process of discovery that occurs where the product backlog changes over time. Due to product feedback, changes in market conditions, technical considerations, and other factors, new stories are added and existing stories are updated, deleted, or re-prioritized
• Prioritized — It is assumed that the most important user stories are at or near the top of the product backlog with the caveat that priorities can change over time

Here are a couple of related concepts that are especially important to understand in conjunction with the DEEP principle and with management of the product backlog in general:

• Progressive elaboration — By focusing attention on user stories at or near the top of the product backlog and by NOT spending time on stories that are further down in the product backlog, teams are practicing progressive elaboration
• Trimming the tail — It is a reality in just about every business context that some user stories in the product backlog are NEVER worked on. Trimming the tail means that you might decide to pivot after delivering only a subset of the items in the product backlog

Things to remember when using the INVEST criteria in user story evaluation

Like so many things in the agile toolkit, the INVEST principle consists of a set of guidelines, not a rigid rule book. There are a lot of common misconceptions and mistakes to avoid when applying the INVEST principle, so here are some tips to keep in mind:

You can’t remove all uncertainty

When inspecting and clarifying user stories, some details may become more clear only after development has started. There is no substitute for ongoing team communication to make sure everyone stays on the same page.

Many attributes of user stories are subjective

For example, it can be challenging when writing user stories to make the story’s business value apparent. Involving multiple members of the team when writing and clarifying stories helps ensure that the business intent and the expected business benefit are as clear as possible.

Perfection is neither desirable nor possible

When articulating user stories, there is a fine line between “good enough” and “over the top.” For instance, a common anti-pattern when estimating is to spend a lot of time debating the size of a particular user story.

Conclusion

The INVEST principle has stood the test of time, by continuing to be popular among agile practitioners, both as a training tool, and in actual practice. By remembering to evaluate whether each story is independent, negotiable, valuable, estimatable, small, and testable, you too can improve team alignment and enhance your ability to deliver software that customers love.

Featured image source: IconScout