Independently Valuable Slices are Foundational to Agile
There are very few practices that are universally optimal in all contexts. Planning the work you intend to do in small, independent, and valuable slices is one of these unicorn practices for any team that wants to be truly Agile.
INVEST is an acronym that stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable. Bill Wake created the mnemonic to serve as an easy way for people to remember the characteristics that tokens for work should possess to be truly effective. These principles apply equally well regardless of whether you're writing User Stories, or any other type of backlog item, as the slices for your product. Let's examine why these characteristics aren't something you can cast aside without giving up many benefits of Agile.
Independent
When product slices are independent from each other, you can easily optimize the order of your backlog without concern for how a change to one slice affects one or a dozen other slices. You can bravely prune slices from your backlog when you are confident that dependencies between them are rare. When change happens, you won't have numerous dependencies to analyze that make change expensive or less likely to be accepted. All of this means you can swiftly respond to new information or adapt to changes in the environment, which in turn means better outcomes for the user.
Negotiable
Slices of work you plan to do need to be negotiable. This requires that they are not an explicit description of the end results. The team can negotiate together, and with their users, to find the right solution during development. In other words, the implementation is not specified in the slice. A well written slice can be satisfied dozens of ways without having to rewrite it. If you find yourself rewriting slices during development because the implementation is changing, it is because they weren't written in a negotiable manner. Negotiable slices also defer detail until just-in-time. This means your team has the latest information possible and can benefit from what was learned when developing the story. There is also an efficiency benefit from decentralizing some decisions and allowing them to happen during the work.
Valuable
Any user, stakeholder, or team member should be able to read a slice and understand the value it will provide. In addition to representing something of value to the user, slices should be written in a way that users (and anyone else) can easily understand. Unlike legacy development practices that served up horizontal layers of technology that weren't usable on their own, your slices should cut through those layers to become a whole piece with everything needed. That means we could potentially release any individual slice into production if we want or need to.
Estimable
Slices should be the type of thing a team can estimate relative to other slices. That is, they should be able to say one slice is about the same size, smaller, or larger as another. If not, either the story isn't understood well enough or it's too big to be estimated. Those that are too big need to be split into two or more stories to make them easier for the team to digest. Slices that the team doesn't understand need more conversation, rewriting, or more research. Teams that are practicing No Estimates need to be able to understand the relative size so that they end up with slices that are roughly the same size.
Small
Smaller slices improve agility. Slices that are too big are much harder to understand and much harder to orchestrate. If they're allowed to remain as too big they accumulate more risk than a small slice. The longer a particular slice of a product is in progress before it is done, the riskier it is. There are more unknowns, and there is a greater delay in discovering missteps. Small slices provide those tight feedback loops and ability to quickly change direction that make you more Agile.
Testable
If you can't think of how to test a slice, then it isn't clear enough to spend valuable time developing. These tests can be functionality that's apparent to the user, or they can be non-functional characteristics you know are needed. In the rare case you cannot find a way to slice it up and deliver something valuable to the user, at least deliver something that is testable by the team as a steppingstone to user value. Determining how to test a slice during refinement can sometimes be challenging but is a critical tool to ensuring quality.
You may have noticed that some of these characteristics can be in conflict with each other. An ideal slice has all of these characteristics but sometimes it's hard to write slices that are independent, valuable, and small. That conflict is good!
Working within constraints is a great way to enhance creativity. Finding the right balance requires you to put just enough effort into writing better slices. You can look at them from different perspectives and find the best ways to write them in the first place or split them later on. Sometimes it is impossible to write a slice that is all three of these things. Sacrificing small so that you can have something independent and valuable is the right compromise to make. Doing it the other way around gets you back to a place where you have too many dependencies to manage and too many parts to wrangle before you can provide value. Writing too many large slices is also problematic but is easily solved by recommitting yourselves to INVEST and slicing them up.
Responding to change quickly is a cornerstone of Agile. Writing your slices with these characteristics is necessary to be able to do so. Starting your Agile journey with these basics in place will be a boon to everything you do. If you're working in an environment that struggles with change or where managing the work feels like it's harder than it should be, it's time to reinvest in this foundational practice.
