E is for Estimable

This content is syndicated from LeadingAgile by Mike Cottmeyer. To view the original post in full, click here.

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. 

Leave a Reply

Your email address will not be published. Required fields are marked *

nineteen + 17 =

There are 101 ways to do anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”



To explore how we can help you, please get in touch