Jeremy Jarrell

How to INVEST in Your User Stories


If you’re a product manager, user stories are a critical part of how you interact with your team. Nothing trumps a face-to-face conversation, but the key to starting that conversation is a good story.

For example, imagine that your team is building an e-commerce site that enables college students to sell their books to other college students at the end of the semester. Rather than selling to an intermediary, such as a university bookstore, this site would let college students to sell their unused textbooks directly to their peers, thus allowing them to keep more of their profits. As a product manager, you might start the conversation with your team with this story:

As a college student

I would like to sell my old textbooks

so I can make money.

On the surface, this story seems to have all of the basic building blocks of a great user story. It clearly specifies a target persona that will benefit from the new capability described by the story, specifies what that new capability should be, and even describes what value the persona will receive from that capability.

But is this story enough to start the conversation with your team? What if there were a simple test that could tell you?

A good user story involves refinement

Illustration by Moe Bonneau.


Luckily, there is a practice that can help, and it’s called INVEST. INVEST represents a specific set of qualities that mature stories tend to exhibit. Although not every quality will apply to every story, the more qualities that your story exhibits, the more likely it is to be ready for consumption.

So what are these qualities? INVEST represents these six qualities that are often considered desirable in a user story:

  • Independent: The story can be delivered independently of other stories. Note that this doesn’t mean that stories can’t have prerequisites, only that the stories may not be so coupled that they must be delivered in parallel.

  • Negotiable: While we prefer stories written in a clear and unambiguous language, stories should not be written to such a level of detail that they become overly restrictive and prevent your team from arriving at the best solution themselves.

  • Valuable: Every story that’s delivered should make your product more valuable—period.

  • Estimable: Every story should provide enough information to equip your team to make a reasonable estimate of that story’s complexity. This is because whether or not we can estimate a story’s complexity is often a great indicator of how well we actually understand that story.

  • Small: Smaller stories are easier for your team to understand and therefore are simpler to deliver. Plus, the smaller a story is, the less risk that may be lurking under its covers.

  • Testable: For each story that you write, you should be able to determine whether what was delivered met your expectations. To do this, the story must be written in a clear enough manner as to remove any ambiguity of what the end result should be.

Let’s look again at our story from before, but this time through the lens of INVEST.

As a college student

I would like to sell my old textbooks

so I can make money

For example, does “sell my old textbooks” describe a story that is small and independent? Perhaps not. Although this higher-level description does leave room for negotiation of how your team can best deliver the story, a more specific description may better enable that negotiation. What if you revised this story to better reflect how a college students may sell those textbooks?

As a college student

I would like to list my old textbooks for sale

so I can make money

This new version provides your team with a more refined vision for this capability that not only reduces the ambiguity and scope of the story, but also makes it more estimable because the team now has a better idea of what you have in mind. And because the story is now more clearly defined, it’s more testable, too.

But what about value? Is making money really the ultimate value that this story might yield to the college student? That’s definitely an end result, but this value statement doesn’t necessary add context to the story. Great value statements help your team better understand the why behind the story by providing clues to what a user might stand to gain after the story has been delivered. Let’s try to rework this story’s value statement to make that more clear.

As a college student

I would like to list my old textbooks for sale

so I can sell my textbook to the highest bidder.

That’s better. Your team now has a clearer understanding of what value the story will yield to the user once it’s delivered, which will provide clues to the complexity that may be inherent in this story. This additional context will better enable your team to negotiate tradeoffs that may allow them to deliver the story more effectively.

Getting more from INVEST

So now that you’ve seen what the individual qualities of INVEST are, let’s talk about how you can use INVEST to improve the quality of your own stories. To do this, we’ll start by talking about what each of these qualities has in common.

First, notice that while each of these qualities asks for a simple “yes” or “no” answer, how you arrive at that answer is subjective. For example, is your story valuable? Before you can answer yes or no, you must first define exactly what value means to your product as well as how that value will be measured. What about negotiable? Is your story negotiable enough? Once again, it’s up to you and your team to agree on how you strike the balance of defining your stories clearly enough so that they’re unambiguous, but not so well defined that they restrict your team’s creativity. This fostering of a deeper discussion across your entire team is the magic of the INVEST technique at work.

Next, notice that many of the INVEST qualities seem to support other qualities. For example, smaller stories naturally lead to more testable stories because smaller stories naturally become more concise and less coupled to other stories. Additionally, smaller stories also tend to be more estimable because these stories are naturally easier for a team to understand.

But not all qualities set up such a natural, virtuous circle. In fact, some qualities act as a balancing force to other qualities. For example, while in general we may prefer smaller stories, we don’t want to create stories that are so small that they don’t yield any meaningful value. For example, we want to avoid breaking stories into such small pieces that each piece is too small to move the product forward on its own.

The INVEST qualities support each other

Illustration by Moe Bonneau.

Putting INVEST to work for you

Ensuring that your stories adhere to the qualities described by the INVEST technique can result in significant improvements to not only your stories but also your own communication with your team. But where should you start?

It would be unrealistic to expect that every story in your product backlog conforms to INVEST. Not only would this be time consuming, but overinvesting your time in stories further down your product backlog might also discourage you from changing those stories as you learn more about them in the future. Instead, INVEST is most appropriate when applied to those stories that are on deck for your next iteration. At this stage, you can be reasonably confident that you’ll make the investment in delivering those stories and you will have also learned more about those stories from your experience in previous iterations. At this point, it makes sense to spend the extra time ensuring your stories adhere to the INVEST qualities to improve your communication with your team.

By applying INVEST to those stories that are on deck for your team to deliver—and applying this technique at the right time—you can dramatically improve the level of communication between you and your team, which will dramatically improve the quality of the product that your team ultimately delivers.

Jeremy Jarrell is an agile coach who helps teams get better at doing what they love. When he’s not mentoring Scrum Masters or Product Owners, Jeremy loves to write on all things agile. You can read more of his thoughts at, see his videos at Pluralsight, or follow him on Twitter @jeremyjarrell.