INVEST in User Stories

May 03, 2022

9 min read

Are you jonesing for a new acronym, a method that will improve the efficacy of your user stories? Then you’ve come to the right place.

Origins of the INVEST Mnemonic

Bill Wake developed the INVEST acronym around 2003 to define the characteristics of good user stories.

He started by brainstorming a list of qualities he associated with exceptional user stories. Next, he grouped similar terms into clusters. To create a mnemonic that would stick with people, he aimed for four to six groups and boiled each grouping down to a single word that captured the essence of each cluster.

The more you know rainbow star

Fun fact: INVEST was almost VESTIGE

After some effort, he identified representative terms that could also spell INVEST.

What does INVEST Stand For?

INVEST is an acronym for the terms Independent, Negotiable, Valuable, Estimable, Small, and Testable.

Since not all of these words are self-explanatory (and super short blog posts don’t rank), let’s dive into each.

Independent

A story is independent when the team can develop it as an atomic unit separate from the consideration of any other user story.

This quality is all about reducing dependencies. We want to be able to work the stories in any way without some relationship between items constraining us.

Bill Wake suggests that there are three types of dependent stories we should concern ourselves with:

Order
Overlap
Containment

Order

We have an independent story when we can complete a product backlog item in any order while avoiding the necessity to deliver a less valuable story first. If what is most beneficial to the customer is the 3rd product backlog item, let’s move it to the top of the Product Backlog and work that sucker first. I’d rather not have to explain to a customer that they have to wait for us to finish something they could care less about to get what they want.

If the customer finds the most value in the pudding, I want them to have their pudding without requiring them to eat their meat.

In his book User Stories Applied, Mike Cohn gives a great example of this in action including two options to resolve the dependency. Let me provide this in terms of a metaphor because that’s how I roll.

Two water bottles, one blue, one sparkly standing on bamboo desk — My Mermaid Sparkle and Aqua Blue water bottles.

Imagine it’s time for me to wash my water bottles. They’re both the same size, even the same brand, and the only difference is the color. However, before I can wash the first water bottle, I need to allow the water to run for a minute to get hot. Although it will take me two minutes or less to wash each bottle, the first one will take three minutes since I’m waiting on the water.

I don’t want to create a separate user story for letting the water get hot because that has no customer value. If I give the aqua blue one a higher estimate than the mermaid sparkle one, that then presupposes that I’ll wash the aqua blue one first. This assumption may not be accurate and may be subject to change as we get closer to starting the work. As an aside, don’t judge me; those are the actual names of the water bottles; I’m not just calling it mermaid sparkle for shiggles.

One option is to combine both bottles into a single Product Backlog Item and estimate that. This approach is acceptable as long as the combined Product Backlog Item isn’t too big to be completed in a single iteration.

The other option (and one I’m ashamed I didn’t think of before reading Cohn’s book) is to call the stories ‘First Bottle’ and ‘Second Bottle’ instead of ‘Aqua Blue Bottle’ and ‘Mermaid Sparkle Bottle’. Then we simply estimate the first one higher to account for heating the water. We can slap the color on the stories later if needed, but it’s irrelevant for the conversations and estimations.

Wake suggests that this type of dependency isn’t the worst. Most likely, the customer will want the functionality implemented in the same order that we’ll technically need to implement them. After all, there’s a 50/50 chance of it, even with no other logic coming into play.

Selfishly, as the resident Jira guru, I don’t want the responsibility of remembering that one issue has to come before, after, or with another. It adds a level of overhead and waste to managing the Product Backlog. Named as suggested above, managing the Product Backlog Items become a bit easier.

Overlap

This dependency type was more challenging for me to wrap my head around. Overlap is when two or more stories describe the same functionality.

Let’s pretend I’ve left my husband instructions to pay some bills. The car insurance is due, and we need to pay off the credit card (Dave Ramsey would be disappointed).

He’ll need to log into the bank and access the checking account in both cases. Specifying the directions and login information for the checking account in multiple places introduces the risk of information becoming out of sync. We might update the login credentials on one card but not the other, but we can reduce this risk by decomposing user stories.

Log into the bank and access the checking account
Pay the car insurance
Pay off the credit card balance

Consolidating the information in one place reduces the risk of becoming out of sync.

Overlap gets increasingly confusing as the number of places we specify the functionality grows. When we need to have a conversation about that capability, we’ll be shuffling back and forth between multiple user stories trying to put together the whole picture. It becomes hard to manage and creates waste.

Overlap is an organizational issue. We need to think about the customer journey from beginning to end and ensure we’ve covered the whole gambit. Also, we should verify that each topic is covered only once.

When we have a huge process that we’re trying to document this way, it can be hard to manage at the story level without the means to see an overall big picture. A Story Map is a tool that we can use to keep up with the individual stories and how they fit into the overall process.

Containment

Containment is a dependency type introduced by our need to group similar functionality. Nearly every application has some concept of a hierarchy above the user story, though terminology may differ across tools. In Jira, you’ll find epics, milestones, and initiatives. Azure DevOps, on the other hand, uses features and epics. There is no consistency in the community regarding these collective constructs, but most teams will have access to some form of hierarchical grouping.

Hierarchies are helpful because they allow us to move our focus up a level and talk about a logical grouping of user stories versus each individual Product Backlog Item. However, it becomes dangerous to consider this higher grouping as deliverables instead of recognizing that releases will be composed of various stories from the more granular level.

Lady standing in front of three mannequins pointing to shopping bags — Just because the clothes are arranged into outfits doesn't oblige you to purchase the entire set.

Imagine shopping online and coming across a couple of outfits you like. Each ensemble costs about $200. That’s a lot to drop on some clothes, but you feel like they’re your style. Considering the shoes are included, maybe that isn’t such an unreasonable price. Come to think of it, the sneakers are your favorite part, and alone they are much cheaper. Then why not buy only the shoes?

If our customers find the most value in story A from feature Y and story B from feature Z, let’s give them what they want instead of buying into this fallacy that we have to deliver an entire feature before moving on to the next.

Hierarchies can be useful but don’t allow them to influence your prioritization of customer value.

Negotiable

A user story is negotiable when developers can work with customers to develop the best solution for the need instead of being obedient to what the customer documented on the request.

Negotiable refers to the collaboration between the developers and users to reach a shared understanding of the need.

“Customer collaboration over contract negotiation”
-Agile Manifesto

The agile manifesto tells us customer collaboration is more valuable than contract negotiation. One anti-pattern of user stories is that teams treat them like mini-requirements documents. If it’s not written on the story card, it never happens. Treating them as a placeholder for conversations is a better application of agile user stories.

Referring to user stories as requirements is a bit of a misnomer. In traditional project management, requirement documents specified all the functionality necessary for the product to be a success. Teams would use those documents like a checklist to complete the project. In agile approaches, it’s more of a collaborative pursuit. All requests are questioned and ranked against others, prioritizing what we believe provides the most value.

The relationship between the development team and users is transformed from an order taker to a strategic partner.

Negotiation shouldn’t be simply ‘allowed’; it should be core to our processes. Developers work closely with the users (or at least a user representative like the Product Owner) throughout the Sprint to clarify the request.

The term negotiable in this acronym always threw me off a bit. Negotiation is more about collaboration, but ICVEST wouldn’t have caught on nearly as well as INVEST.

Valuable

A user story is valuable if, once completed, the customer gains some benefit from it.

That probably seems like common sense, but this is trying to prevent the natural inclination to split work by functional role. When you have an agile team that has not embraced the idea of cross-functionality, slicing features to line up with team members’ skills will seem logical. So you end up with an item for the database, the UI, and the integration layer.

These layer-specific items alone do not provide customer value. The development team would need to complete all stories before the user could see the functionality work end to end. I’ve seen this concept explained as everything with layers ranging from cake to tiramisu.

My preferred metaphor is a seven-layer dip. No one wants just the refried beans, and the point is to give a useable slice to the customer.

Estimable

A user story is estimable when you know enough about the request to provide a rough guess at an estimate.

We already know that estimates aren’t going to be accurate. So, we’re just trying to get to a good-enough estimate. We need this information for two main reasons.

First, having a story size will help the customer determine what has the most significant impact. Let’s say my feet are cold. I can get a pair of socks today for a low price, or I can order a deluxe foot warmer for five times the price and wait two days for it to get here. I have to tell you, I didn’t know foot warmers were a thing until I came up with this metaphor, and even though I’m amazed, I’m still going to go with the socks. It might be hard to decide without knowing (even an estimate).

The second reason we need to be able to estimate user stories is to uncover ambiguity. Generally, we don’t understand the request when we can’t provide a ball-park estimate. Given that the primary purpose of a user story is to reach an understanding, ambiguity is something we’d want to avoid.

The primary goal with estimates should be to spend as little time as possible. You can spend more time, but in all likelihood, your calculations will not be any more accurate. Thus, your time is better spent delivering working software.

Small

A story is small when a development team can complete it within a single Sprint.

Smaller stories have several benefits:

More accurate estimates because it’s easier to see the whole picture
Makes it easier to combine stories if needed to reduce dependencies
More likely to finish in a single iteration
Enables us to show progress more quickly
Easier to transition to other teams members (like QA)

One of my favorite quotes is from a book called Juggling Elephants:

“The result of trying to juggle elephants is that no one, including you, is thrilled with your performance.”
-Jones Loflin

I’m sure I will quote this 1,000 times on this blog, but as I said, it’s my favorite.

In this context, small, agile user stories help us avoid juggling elephants. When you have larger stories that represent a ton of work, transitioning them through your process is doomed to fail.

It’s better to start with smaller stories, but if larger stories already burden your team, you can get into a better place by splitting what you have into smaller bites.

Testable

A user story is testable when we can verify the intent has been satisfied before the end of the Sprint.

If we cannot define a way to test the functionality, we don’t understand the story, or it may be of low value. Both scenarios we’d want to avoid.

We’re not talking about automated testing; that will come during the implementation phase. We’re talking about the criteria that the user or Product Owner will use to determine if we’ve implemented what they expected.

Tree fallen in empty forest — If a tree falls in the woods, and no one is there to hear it, does it make a sound?

A user’s lack of ability to specify acceptance criteria reminds me of that infamous mystery: if a tree falls in the woods and no one is there to hear it, does it make a sound? Does it even matter if we’re delivering working software if the functionality has so little value that no one can determine its success?

If the user can’t define success criteria for the item, why are we building it? Hypothetically we could update the code to add a comment line that reads: “Harry was here” and then deploy the application and claim the functionality exits. Who would know?

Test criterion is a barrier to entry that should suffice to prevent customers from requesting something they don’t understand or something that has meager value.

Removing ambiguity is an additional benefit on top of ensuring value.

When the user doesn’t understand their request, it sets everyone up for failure. Getting clarity on the acceptance criteria in the beginning, will ensure we’re building the right thing.