Being Agile with independently valuable slices
There are very few practices that are universally optimal in all contexts. Thinking about and 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.
The INVEST mnemonic was created by Bill Wake to serve as an easy way for people to remember the characteristics that tokens for work should possess to be the most effective. INVEST is a mnemonic acronym that stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable. These characteristics 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 slices are independent from each other, we can easily optimize the order of our backlog without concern for how a change with one slice affects one or a dozen other slices. We can bravely prune slices from our backlog when they aren’t dependent on each other or those dependencies are rare. When change happens, we won’t have a bunch of dependencies to analyze that make change expensive or less likely to be accepted. All of this means we can swiftly respond to new information or adapt to changes in the environment which means better outcomes for the user.
Negotiable
Slices of work we plan to do need to be negotiable. This means that they are not an explicit description of the expected output and that 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 re-write it. If you find yourself rewriting slices during development because the implementation is changing, it’s because they aren’t written in a negotiable manner. Negotiable slices also defer detail until just-in-time which means we have the latest information possible, and are able to benefit from everything we’ve learned, when developing the story. There’s 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, it should be written in a way the user (and anyone else) can easily understand. Unlike legacy development practices that served up horizontal layers of technology that weren’t usable on their own, our slices should cut through those layers to become a complete 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. A team should be able to say whether 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 wrap their minds around. Those 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 all of the pieces. If they’re left 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 too many unknowns and there is added delay in learning about missteps. Small slices give us those tight feedback loops and ability to quickly change direction that make us 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 we know are needed. In the rare case that we 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 stepping stone to user value.
You may have noticed that some of these characteristics are 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 us to put just enough effort into writing better slices. We 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’s impossible to write a slice that is all three of these things. Sacrificing small so that we can have something independent and valuable is the right compromise to make. Doing it the other way around gets us back to a place where we have too many dependencies to manage and too many parts to wrangle before we 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.
About the Author | Mike Brewer
Mike is an Agile Coach that believes in the ability to create better outcomes for customers, workers, and companies through the values and principles of Agile. You can connect with him on LinkedIn.
