If Estimates Were Accurate, We’d Call Them Actuals

Almost everyone agreed that we need to get better at estimation.

I heard this recently from a team. It’s not the first time, and I’m sure it won’t be the last. Teams struggle with estimates; others needlessly obsess over it. And while I agree with the sentiment, it’s true but useless. It’s unactionable. In order to appreciate how teams gets there, let’s take a step back and ask ourselves a simple question.

Why estimate?

Ask the team, and I expect we’ll hear that we or others need to know how long the work will take. Or that we’re required to put story points to all the things we do. Or we need to create a roadmap so leaders know when we’ll be delivering. While all this is true, none of it is at the heart of why, which is to make the implicit explicit. Unfortunately, even that neglects something even more fundamental.

Estimates are about mathematics. Expectations are about human connection. That difference matters.

Expectations build connection between us and our customer, between us and our leaders, and even between us and our fellow team members. Estimates though? That’s often something we pad in fear we’ll be taken to task for missing them. Or it’s the topic of endless debate about when work rolls over from one sprint to the next, should we reestimate it. Who cares?

Even so, expectation setting comes at several costs:

• The cost of creating shared understanding. Again, making the implicit explicit.
• The cost of locking scope for some measure of the work.
• The cost of adjusting expectations in cases where we made improper assumptions about that locked scope.

In nearly all circumstances, the benefits of expectation setting outweighs those costs, but I mention it for another reason. Time and again, I’ve watched teams that are only interested in “better estimates” after the work is complete. Unfortunately, that misses the mark.

Creating shared understanding doesn’t come for free and must be paid before we begin the work, not after.

As coaches, I think it’s our responsibility to help teams recognize when we’re about to fall into this trap, and when we’re willing to pay the costs, we should provide the tools to succeed.

What Are These Tools Then?

First, it starts by being less concerned about those estimates–the math–and, second, we should borrow from how we humans already estimate on daily basis. After all, guessing isn’t new to us. We’ve been doing it our entire lives.

Imagine we’re planning a road trip.

This isn’t the first time I’ve used a similar metaphor, but it’s worth repeating. So let’s say we want to take a trip from Los Angeles to New Year City. To do so, we open up Google Maps and plug in where we start and end our journey. From there, we can decide where to book hotels, how many days in total it’ll take us, and maybe even sites to take in along the way.

There’s no way it can be this straight forward, right? Our team’s work is entirely too complex to borrow from something so simple. It’ll never work. In some cases, the team is right. In most others, they’re wrong. Here’s a few common arguments:

• Cities like NYC don’t move, but our final product continues to morph. You’re right. NYC isn’t going to uproot itself and move a few hundred miles. It’s stationary. Although our product’s destination changes, we still know what direction we’re headed so isn’t it fair to say our next “fuel stop” won’t change? And where we spend the night likely won’t change either, right? If we think in small, incremental pieces, the metaphor holds.
• We don’t own the work end to end. We have all these other teams we have to work with. That’s a problem. So what are we doing about owning the work from beginning to end? Should we invest more here instead of trying to “estimate better?” Still, if there’s little we can do here, consider the case where we instead fly to NYC. We take this into account by getting to the airport two hours prior to and impatiently waiting. So while flying saves us time, it costs us in other ways like the wait, a potentially cancelled flight, or having to bum a ride to and from the airport. Again, the metaphor holds if we’re willing to pay for and manage the dependencies.
• We’ve done road trips, but we’ve never done this kind of knowledge work. I concede the metaphor falls apart here. Nonetheless, we can mitigate this by “chunking” the work up as small as possible. Doing so limits effort and limits the number of assumptions made. And if done properly, it allows us to put the work in front of our customers to validate that our solution solves their problem.

How Do We Apply This With Our Teams?

First, walk the team through a metaphor like the above. Use something that resonates with you–the coach–while simultaneously helping teams dampen the notion of estimation and amplify the notion of expectation setting.

Second, ask the team for their own examples of how they estimate or guess in their personal lives. Dig into how and why it works for them and in what ways they intend to borrow from it as we set expectations.

From here, figure out in clear and certain terms what the team intends to do differently and gain agreement that effort is required up front and before the work begins if we are to do this well. Often, it means not doing something else in order to make room for this.

Mostly though, it requires invitation over imposition.

Finally, assuming the team is willing, provide coaching in groups of two or three around conditions of satisfaction–also known as acceptance criteria. Conditions of satisfaction is something oft misunderstood, and if used properly can help teams shift work from large batches to small chunks, creates a clear expectation of done, and can help teams transition toward delivering working, customer-focused deliverables.

So what’s that look like? It borrows from some of Mike Cohn’s work, but I think I’ve drone on enough for today. I’ll write about how I set up those conversations the next time we chat. We’ll talk again soon.

---

Update: I promised a follow up digging into conditions of satisfaction. That post can be found here. Enjoy!

---