E is for Estimable

I’ve been a big fan of Bill Wake’s INVEST model since I first learned about it through Mike Cohn’s book on user stories. Like every other agile blogger out there, I’ve shared my take on these principles and what they mean for product owners writing good agile requirements. The more I teach these concepts though, the more I find myself spending a little extra time talking about what it means for a story to be estimable.

On the surface, the notion of estimable seems pretty clear. In order for a story to be ready for a sprint, the team has to be able to determine what it’s going to take to build it. They have to be able to give an estimate. Why is the ability to put an estimate on the story so important? Well… if the team does’t know what the story is going to take to build, they don’t know if they can get it done by the end of the sprint.  If they don’t know how big it is, they can’t make a commitment to build it.

If the team cannot consistently make and meet commitments then velocity never stabilizes. When velocity isn’t stable, teams aren’t predictable delivering sprints. When teams aren’t predictable delivering sprints, we have no idea what we can deliver releases. When we don’t know what it takes to deliver a release, roadmaps fall apart and we have no ability to plan forward. In multi-team environments, this is catastrophic because the teams get out of sync and no one is able to deliver an integrated product.

But wait, we have an answer for fixing a story when a story is not estimateable… all we have to do is put in a spike! What’s a spike you ask? Usually I explain a spike as an investment the Product Owner makes to figure out exactly what needs to be built and how the team is going to build it. The Product Owner allocates a little bit of the teams capacity now, ahead of when the story needs to be delivered, so that when the story comes into the sprint, the team knows what to do.

In other words… its an investment to make the story estimable.

Here’s the deal with spikes though… spikes represent risk. Spikes represent uncertainty. If our backlog is full of spikes, that means that our backlog is full of stuff we don’t know how to do. If our backlog is full of stuff we don’t know how to do… that means that our product delivery process isn’t stable. It means that we have no business making commitments at the product level, or even at the release level, because we don’t have a credible plan for getting to done.

One of the things I’ve been talking a lot about lately with my clients… and plan to talk more about here over the next few months… is the idea that the only way to make better estimates, the only way to deliver releases on time and with a reasonable approximation of the scope expected… is to remove risk and uncertainty from what we are building. Removing risk and uncertainty involves doing one of two things: buffering for the unknown or mitigating risk ahead of time.

Buffering for the unknown is always a good idea… but mitigating risk and uncertainty is something that we don’t talk much about. If I want to reduce risk in a sprint, I pull some work forward to do the discovery before I am asked to make a commitment. If I want to reduce risk in a release, I pull some work forward to do the discovery before I am asked to make the commitment. If I want to reduce risk in a project, that means that I pull some work forward to do the discovery before I am asked to make a commitment.

All I’m really saying here is that we need to extend the spike metaphor beyond the level of user stories and sprints and up to the level of features, epics, releases, projects, and products. The more we need to be certain, the more we need to invest (no pun intended) up front to figure out how to build what it is we plan to build. Now, lest you think I am making the case for waterfall… all this is done in the context of small batches, doing just enough just in time, rolling wave planning, and progressive elaboration.

Agile methods accept the fact that some things are going to change… but that doesn’t mean EVERYTHING is going to change. I think it is fair for us to look far enough ahead to have some idea of where we are going, some idea of what we might want to build the next release, and some idea of the risks involved moving our product forward. Sometimes a little bit of planning, at the right level of abstraction, can help us make the case that we need to spend some time in this release getting ready for the next release.

At the end of the day, it all comes down to your context…

If you need to have a stable predictable product delivery process that can reliably look 6 months or so out… I think this kind of an approach is your only option, especially if your team is building a bunch of stuff they don’t know how to build. If your business is content figuring out your product strategy 2 weeks at a time… if a 4 to 6 week planning horizon is sufficient to make your customers happy… feel free to ignore this advice. Most Product Managers I talk to want  to commit at least a quarter out… most want 6 to 9 months.

Putting your product desires on a roadmap is not a strategy. Committing to things that you have no idea you can deliver is not a strategy. Asking the business to throw money at you on the promise we’ll do the best we can do and you’ll get what you get when the money runs out isn’t a strategy. Coming up with a credible plan, proactively mitigating risk, making trade-offs daily, and proactively managing your delivery is what makes your roadmap a reality.

So… next time you are committing to a sprint plan or a release plan… the next time you are laying out a product roadmap and making commitments to the business… ask yourself if the work is estimable. If it isn’t estimable, and you have no idea what it takes to get the work done, then you are assuming a ton of risk for yourself and asking your business to do the same.  In some contexts, some of the time, that is a perfectly fine strategy… just make sure you are intentional about what you are trying to accomplish.

If figuring it out as you go isn’t part of the plan… remember that E is for estimable and act accordingly.