“A story is a placeholder for a conversation.”
It’s no secret that agile teams thrive on collaboration. So much so, that this phrase has been echoed as a warning against over-detailing stories for decades. But, even the most agile-leaning teams tend to benefit from some refinement to their stories to create clarity on what the team is trying to achieve with those stories.
But how do you know how much refinement is enough? That’s where INVEST comes in.
Created by Bill Wake, INVEST is a set of criteria that specifies six qualities that are commonly associated with well-refined and immediately actionable stories. Evaluating your story against these criteria can help you determine if your story is refined enough, or if there are still opportunities for improvement.
At a high level, the INVEST criteria are:
Often, each piece of the INVEST criteria is framed as a simple yes or no question. But high-performing agile teams realize that each piece of the INVEST criteria is often the start of a more in-depth, much more valuable conversation.
Beyond asking whether a story meets a particular piece of INVEST criteria, taking the time to ask why it fails that criteria or, how it could better adhere to that criteria not only improves the quality of the story, but it also improves your team’s understanding of that story.
Let’s walk through each piece of the INVEST criteria and discuss how each can be the beginning of a more in-depth conversation to not only improve the quality of the story but your team’s understanding of why they are delivering the story, in the first place.
We’ll start with whether or not the story described above can be tackled by your team independent of other stories on your team’s backlog. But rather than merely answering Yes or No, we want to dive deeper and ask what would make it more independent from other stories.
Often, an indicator of this is that the story can only be developed in parallel to another story. If this is the case, encourage your team to ask whether the entire story is coupled to the other story or only part of it. If so, then this may be an indicator that you should split the tightly coupled portion of the story into a separate story.
Next, we’ll ask how much latitude the product team has to deliver the story. Great Product Managers communicate with their teams in outcomes rather than outputs. This means that rather than specifying exactly what output the team must deliver, they instead focus on the outcome the team is trying to create. This subtle but essential difference grants the team the latitude to decide how to best achieve the desired outcome given the resources at hand.
This same approach can also be carried to the story level. While great user stories should be refined enough to help the team understand exactly what they are trying to achieve, they should not be so refined that they constrain the team’s ability to innovate. Often this innovation yields new ways to achieve the same outcome with the same or less effort.
This flexibility of approach between the Product Manager and the product team is why negotiable user stories have become such a hallmark of an agile approach.
Perhaps one of the most important qualities of a great user story is whether or not the outcome the story is describing is even valuable.
Value can take many forms. Perhaps a story is valuable because it enables a user to complete an important task, therefore making that product more valuable to the user. On the other hand, perhaps a story isn’t directly valuable to an end user, but instead simplifies a process in the company that creates the product, allowing the company to operate with greater efficiency.
But whatever form that value takes, simply deciding whether or not a story provides value isn’t enough. Both a Product Manager and a team should consider if the story provides value on its own, or does it depend on other stories to be delivered before that value is realized. While it’s natural for some stories to depend on other stories, a story that provides no value on its own might be a symptom of a story that’s been sliced too small and may need to be combined with other stories. On the other hand, if a story is deemed valuable, it can also be helpful for a team to consider what additional steps they can take to enable that story to deliver more value, for a similar amount of effort.
In any case, delivering the story must create some value for at least one of the product’s stakeholders. Otherwise, the team might justifiably ask, “Why are we spending time on this story, in the first place?”
Perhaps the most telling check for whether or not a story is well enough refined is, can your team make a reasonable estimate of the complexity of that story, based on the information provided.
Stories that are poorly defined often yield questions which can make them difficult for your team to estimate. For your team to put a reasonable estimate on a story, they should have some idea of how they would approach that story, or at least understand its complexity relative to other stories they have tackled in the past. If a story is so vaguely defined that your team can’t even understand the problem you are asking them to solve, then how do you expect them to estimate how long it will take for them to solve it?
But instead of merely asking, “is this story estimable?” elevate the discussion by asking what would make this story more estimable? For example, are there unanswered questions or outstanding items that are preventing your team from understanding exactly how complex the story is? If so, then what additional information can you provide to your team to help remove some of that uncertainty?
Size is one of the most critical factors that can determine your team’s success with a story. However, rather than ask “is this story small,” the more important question is, “can we make this story smaller.”
Small stories have many advantages over larger stories, such as being inherently less complex, and therefore easier to understand. When high-performing teams discuss a story’s “size,” they most often are not talking about the time it would take to complete a story, but rather that story’s complexity. Put another way, how difficult is it to hold all of the story’s details in your head while you’re discussing it.
Many of the INVEST criteria are tradeoffs between one another, which means that teams should be careful not to overemphasize one criterion at the expense of others. There is possibly no greater example of this than the tension between Small stories and Valuable stories. While smaller stories have an inherent advantage over larger stories, we should be wary of slicing stories so small that they no longer yield any meaningful business value on their own.
The final piece of INVEST is the idea of testability. But, like with all other parts of the INVEST criteria, it’s not enough to ask, “is this story testable?”, but rather, what would make it more testable.
For example, is the story so vaguely defined that the outcome, and the acceptance criteria that describe that outcome, are not clear? Or, is this story so tightly coupled to other stories in the sprint that it will be impossible to test in isolation from those other stories. If the answer to either of these questions is yes, then you should consider what steps you can take to make the story either more clearly defined or less coupled to other stories.
However, be wary of over-specifying the outcome of the story to such detail that you constrain your team’s creativity when delivering that outcome. Like all elements of the INVEST criteria, testability is a constant tradeoff against other factors.
The depth to which you discuss each of the INVEST criteria will vary for every team. In addition, the value attributed to each piece of criteria is likely to shift depending on where you are in your project lifecycle. For example, early in a new project, teams are likely to benefit the most from focusing on Independent and Small stories as a strategy to help mitigate the risk that’s often so prevalent in a new project.
However, as the project draws to a close, much of the discussion is likely to focus on the Value aspect of stories. This is because, in a properly prioritized project, much of the work done in the later stages of a project often yields diminishing returns. For this reason, teams should pay close attention to the tangible value this later work is producing compared to the potential value in allowing the team to move on to projects.
In any case, as long as your team is having a genuine conversation about the work at hand, they’re likely to reap significant benefits from applying the INVEST technique to their own user stories. This is because the true value for any team lies in the conversation the story generates, not the story itself.
Category: Productivity Updates Community
