Revisiting INVEST 20+ Years Later

September 30, 2024

“We can’t pick up that User Story because it doesn’t follow INVEST.”

If you work with User Stories, there’s a good chance you’ve heard someone say this during refinement. And I’ve got news for you if that’s how you use INVEST, then you’ve missed the point of the acronym entirely.

INVEST was invented by Bill Wake in 2003, and Mike Cohn helped popularize it in his book User Stories Applied. The INVEST acronym functions as a checklist that you can use to check the quality of your User Stories — and here’s the key distinction many people seem to misunderstand: INVEST should be used as you work on them, not only before you pick the User Stories up.

Let’s revisit the original article where INVEST was defined, and see how it stands up more than 20 years later and what kind of misunderstandings have creeped in over time.

What’s INVEST?

INVEST stands for:

I – Independent

N – Negotiable

V – Valuable

E – Estimable

S – Small

T – Testable

I’ll quote Bill Wake for his original definitions so we can explore these together. I’ll add my reflections after working with INVEST and my perspective of more than two decades later.

Let’s start with the first definition: Independent.

Independent

“Stories are easiest to work with if they are independent. That is, we’d like them to not overlap in concept, and we’d like to be able to schedule and implement them in any order.

We can’t always achieve this; once in a while we may say things like “3 points for the first report, then 1 point for each of the others.” – Bill Wake, INVEST in Good Stories, and SMART Tasks

Independent is something to strive for, it’s an ideal that’s not always possible. However, wherever possible we should aim to make things independent, as it will make our life much easier down the road and prevent cascading delays and issues.

I’ve worked in teams where they misunderstood Independent to mean it MUST be independent, otherwise we can’t work on it. That’s never how it was intended.

Negotiable… and Negotiated

“A good story is negotiable. It is not an explicit contract for features; rather, details will be co-created by the customer and programmer during development. A good story captures the essence, not the details. Over time, the card may acquire notes, test ideas, and so on, but we don’t need these to prioritize or schedule stories.” – Bill Wake, INVEST in Good Stories, and SMART Tasks

Here you clearly see the XP context shining through: details will be co-created by the customer and programmer. Many teams don’t have that kind of direct access to customers.

The key thing to keep in mind is that it’s a User Story is not a contract to deliver a specific feature, we should discover the details and acceptance criteria as we go along.

In my experience, this is very different from how most teams work with INVEST. Most teams required the details up-front before prioritizing or scheduling stories. Yes, it should be negotiable, but before we start the work. In this quote you can clearly see it’s meant to be negotiable at every step of the way, not just before refinement.

Valuable

“A story needs to be valuable. We don’t care about value to just anybody; it needs to be valuable to the customer. Developers may have (legitimate) concerns, but these framed in a way that makes the customer perceive them as important.

This is especially an issue when splitting stories. Think of a whole story as a multi-layer cake, e.g., a network layer, a persistence layer, a logic layer, and a presentation layer. When we split a story, we’re serving up only part of that cake. We want to give the customer the essence of the whole cake, and the best way is to slice vertically through the layers. Developers often have an inclination to work on only one layer at a time (and get it “right”); but a full database layer (for example) has little value to the customer if there’s no presentation layer.

Making each slice valuable to the customer supports XP’s pay-as-you-go attitude toward infrastructure.” – Bill Wake, INVEST in Good Stories, and SMART Tasks

A User Story should deliver value to the customer upon completion. Ideally, you’re doing vertical slicing to achieve this. What’s interesting, is that this definition has since been watered down a bit if you look at how it’s described in Wikipedia:

“Sometimes a story might not result in a complete shippable feature in its own right, and it may simply be a measurable step towards that goal.” – Wikipedia, October 2024

That wiggle room isn’t mentioned as explicitly in the original article.

Estimable

“A good story can be estimated. We don’t need an exact estimate, but just enough to help the customer rank and schedule the story’s implementation. Being estimable is partly a function of being negotiated, as it’s hard to estimate a story we don’t understand. It is also a function of size: bigger stories are harder to estimate. Finally, it’s a function of the team: what’s easy to estimate will vary depending on the team’s experience. (Sometimes a team may have to split a story into a (time-boxed) “spike” that will give the team enough information to make a decent estimate, and the rest of the story that will actually implement the desired feature.)” – Bill Wake, INVEST in Good Stories, and SMART Tasks

Here you can see that Bill Wake is trying to make clear that there is enough detail that we may have a rough estimate, which is sufficient for scheduling and planning. The goal isn’t to produce certainty or guarantees, but provide enough information so that we can rank and schedule the work.

Bill Wake has later said he regrets calling it estimable:

“A note of caution: Estimability is the most-abused aspect of INVEST (that is, the most energy spent for the least value). If I could re-pick, we’d have “E = External”; see the discussion under “V for Valuable”. – Bill Wake, Estimable Stories in the INVEST Model

So, don’t waste your time nailing your estimates, get sufficient clarity for prioritization and scheduling, and that’s it.

Small

“Good stories tend to be small. Stories typically represent at most a few person-weeks worth of work. (Some teams restrict them to a few person-days of work.) Above this size, and it seems to be too hard to know what’s in the story’s scope. Saying, “it would take me more than a month” often implicitly adds, “as I don’t understand what-all it would entail.” Smaller stories tend to get more accurate estimates.

Story descriptions can be small too (and putting them on an index card helps make that happen). Alistair Cockburn described the cards as tokens promising a future conversation. Remember, the details can be elaborated through conversations with the customer.” – – Bill Wake, INVEST in Good Stories, and SMART Tasks

The goal of keeping User Stories small is to help make sure there is clarity of what we must do. What’s interesting that he once again stresses the importance of emergence: the details of the User Story will be discovered as we do the work.

Small also means that INVEST is applicable for breaking down work, not necessarily before you’ve broken it down in pieces.

Testable

“A good story is testable. Writing a story card carries an implicit promise: “I understand what I want well enough that I could write a test for it.” Several teams have reported that by requiring customer tests before implementing a story, the team is more productive. “Testability” has always been a characteristic of good requirements; actually writing the tests early helps us know whether this goal is met.

If a customer doesn’t know how to test something, this may indicate that the story isn’t clear enough, or that it doesn’t reflect something valuable to them, or that the customer just needs help in testing.

A team can treat non-functional requirements (such as performance and usability) as things that need to be tested. Figure out how to operationalize these tests will help the team learn the true needs.

For all these attributes, the feedback cycle of proposing, estimating, and implementing stories will help teach the team what it needs to know.”

Here, we can deduce that testable doesn’t mean it has to be testable before we schedule or plan the work. After all, Bill Wake already mentioned the details may emerge during conversations as we do the work. That means the tests may also emerge as we do the work.

All it means that whatever we do agree upon prior to implementation, do we know how to test it? There is still room for emergence, as this is clearly stated in the clarification of the other aspects of the acronym.

Now that we’ve went back to to the source for the original definition of INVEST, what did we learn from all of this?

Don’t Abuse INVEST to be a Gatekeeper for Picking Up Work

One of the surprising things I learned from reading the original article, is that INVEST is not supposed to function as a bouncer or gatekeeper. You should NOT only pick a User Story up if it meets INVEST.

If you believe you can only pick up work once it meets the criteria of INVEST, I believe you’ve misunderstood INVEST as it was originally defined by Bill Wake. There are enough hints peppered through the original article where he stresses the importance of emergence and figuring out things as you go along.

INVEST is an acronym that we should keep in mind, before we pick-up stories and as we work with them. Bill Wake clearly seems to add caution in different explanations that it’s crucial that the work remains collaborative and emergent if you want to deliver the most valuable possible.

INVEST is supposed to help with emergence, conversations and collaboration as we do the work, not to try to nail all details before we start to work as that’s wholly counter-productive.

Reflecting on working with INVEST, I believe one of its biggest limitations is that we often start with work that’s too big and we must still break it down in smaller chunks.

INVEST helps with breaking down the work into useful User Stories, but it doesn’t aid with answering the question: should we even break down the work? Do we have sufficient information to even consider breaking it down in small pieces?

Do we have the right information to consider breaking down this big old oil tanker in small boats?

You don’t need the same information for a large piece of work, as a small piece of work. Independent, Testable, Small, Estimable by definition aren’t relevant when evaluating a large piece of work – you’re not there yet.

One of the first questions you should ask before breaking down a larger piece work, is whether we’re able to reframe the problem we’re trying to solve.

Being able to reframe the problem we’re trying to solve is crucial because:

It assumes we know the problem we’re trying to solve.

We might have a clear problem, but if we can’t reframe the problem, then that means we lack the context and understanding necessary to come up with (potentially) different way of solving the problem. We must first perform more discovery work, to gain a better understanding of the situation and context.

You can solve a problem and create value, but sometimes you can 10X or 100X the value you deliver by reframing the problem the first.

A good example is the reason why elevators have mirrors. A hotel in New York had customers who were complaining about waiting times. The problem was that the elevators were slow. Making the elevators faster would cost 5 million dollars and bankrupt the hotel.

Then someone reframed the problem: what if we make waiting for the elevator less boring and decrease the perceived waiting time? They added mirrors to the elevator.

With that cheap fix, all the complaints evaporated overnight, and that was only possible by reframing the original problem.

This is why asking the question: ‘Is what we’re doing valuable?’ simply isn’t good enough for large pieces of work. The bar should be much higher: did we frame the problem in a way that we can explore different solution options?

Do we have sufficient understanding to potentially reframe the problem is absolutely necessary. It not only ensures we’re rooted in the problem’s we’re trying to solve, but also that we have the option of exploring the problem space before committing to any specific solution.

Keeping this in mind, the question becomes: should we have an acronym to can judge large pieces of work, and not just an acronym for User Stories we intend to deliver?

I believe the answer to that is yes, and that will be the subject of a future article.