We’ve all heard the 80/20 rule: 20% of a product’s features deliver 80% of its value. The challenge? Identifying which features are the true value drivers and prioritizing them effectively. By focusing on these, we can create products that genuinely resonate with customers—without overloading the first version with unnecessary complexity. Instead, we aim to build a lean, impactful version of the product and then refine it iteratively, adding only what enhances customer value.

But how do we break down a long list of feature requirements into a focused, high-value product roadmap?  

One answer lies in the INVEST principle, a framework I first encountered in Vasco Duarte’s insightful book, *No Estimates*. The INVEST approach helps teams break down features into their smallest, functional components, delivering value quickly and efficiently.

Let’s explore what INVEST means:

• Independent: Each story should stand on its own, without depending on another story to be valuable or complete.  

• Negotiable: Stories define *what* needs to be accomplished, but leave room for the team to decide *how* to achieve it.  

• Valuable: Every story must deliver concrete value to the user—no filler or “nice-to-haves.”  

• Essential: These are the must-haves; without them, the product becomes unusable or unsellable.  

• Small: Keep stories bite-sized. Each one should fit comfortably within a single sprint, making them easier to understand and implement.  

• Testable: Stories must have clear, user-focused acceptance criteria that make success measurable.  And ideally associated automated tests to ensure code quality.

INVEST stories act as vertical slices of complete functionality, designed to be delivered independently, verified easily, and aligned with user value. By applying this principle, teams can ensure that each iteration of the product provides meaningful progress—one small, impactful step at a time.

Challenges many teams face:

Independent stories - in reality we often find it hard to determine if a story is truly independent or not. Much of software development has dependencies on other systems, services, functions, modules, etc to work. So how do we determine independence when such dependencies exist? For example if I am implementing a loading screen but my implementation depends on connection to a service in order to test that the screen shows a loading state when the network is slower, how can my story be independent of the service? The service is technically a dependency for my story to be considered “valuable and complete.” Right? Yes, and no. In this case you could mock the service so that you could both illustrate and test the functionality of your loading state on the screen. In this way your story would include building the mock service as well, but elevate the dependency on the actual service (at least for the first iteration). Down the road when the real service is ready we could write another story for that integration work along with tests to validate the functionality is working as expected. 

What is “small” to me is large to someone else - The principle states that the stories are sized to be completed within an iteration. Iterations can be two weeks, up to 4 weeks in standard Agile practice. A 4-week story is a pretty darn big story! Even a two week story can be quite large. We need to utilize our best judgement here and look at the stories we write, asking ourselves, is this truly the smallest, testable, releasable, valuable increment of software I can write? Is this story including too many dependencies? Is this story describing the implementation? Are we including non-essential elements to this story that without which the story would still add value? I often find that many stories can be completed within a week or less. Some DO require more time, and, if given the above line of questioning, you still feel that the story can not be any smaller than two weeks (god forbid four!), then that is the smallest the story is going to be. 

What is meant by a “vertical slice” -  A vertical slice is a fully functional piece of software that spans all system layers—from the UI to the middle tier, down to the data layer. Ideally, this aligns with the INVEST principle for user stories. However, real-world constraints often make this challenging, especially when dependencies—like external services accessed via APIs—are involved. Mocking these services is an option, but even that isn’t always sufficient.

Each system layer has its own complexities, and the APIs connecting them may not even exist yet. This makes breaking down a story into a true vertical slice difficult. The key is knowing when this approach makes sense and when it doesn’t. Vertical slices work best when building incrementally on existing functionality or when implementing new features with minimal dependencies.

When full vertical slices aren’t feasible, it’s okay to focus on the other aspects of INVEST—making stories Negotiable, Valuable, Essential, Small, and Testable—rather than forcing independent delivery. The real takeaway is prioritization. If developing a foundational service first adds value and creates efficiencies for the team, then prioritize that. In practice, teams often need to balance vertical and horizontal slices to deliver the most impact efficiently.

Conclusion

When a team is able to break down implementation stories in this way they get to a point where all stories are roughly the same size. And when we have this, we begin to see a phenomenal thing happen on Agile teams. We attain a predictable delivery cadence!  This is the first step to understanding how to break down requirements into commonly sized, value-driven stories. Once we do that we can finally give “estimating software” the boot and actually do some real data-backed calculations using predictability over speed.