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.
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!
Do you want to get notified when new posts are published? Leave your email below.
6 thoughts on “If Estimates Were Accurate, We’d Call Them Actuals”
Nice article, Tanner. Steve McConnell, who wrote THE book on software development estimation, once told me “An estimate by its very nature must be a range. If it is a single number, it is a target.” So, the only 100% accurate estimate is 0 to Infinity. Of course, no one would accept such a range and ranges in general are generally scorned because many who want them see them not only as a target, but as a constraint and those very people often “encourage” lower estimates, which are “more realistic.”
We stopped estimating items when I was using Scrum at a company because it caused too much havoc and gaming, especially with story points. And when one team was admonished for not getting as many story points accomplished in a Sprint, all kinds of dysfunction broke out. The classic was “We’ll just increase our story points by one factor and then we’ll outscore them!” I commented, “So, you still score ’40 baskets’ in the game, but instead of getting 80 points, now you’ll get 160.” We’re no more productive, but we get more credit for productivity. Excellent!!!
I discourage using story points in my CSM and CSPO workshops, especially after Ron Jeffries told me that creating story points was the biggest professional malpractice he committed in his illustrious career. Of course, people invariably ask “Then how do we estimate?” I reply rather cavalierly, “Don’t estimate.” The sometimes contentious discussion then ensues – and it usually ends up at the point of “Why are we estimating and for whom?” Many times the answer does not include “For us, because we feel it’s important.”
It is rare that we estimate for our benefit, but estimating can be a clue to how much or little understanding we might have about something. It can also produce important discussions. But, we can put constraints around our estimates to be valuable for us such as “Let’s try to keep the time to build and implement something to no more than 2 days of work end-to-end.
Ultimately, what we get done in a time frame (e.g. a Sprint) is what we get done and the discoveries, realizations, value changes, road bumps, Murphy problems, and “OMGs” all have an unforeseen affect on our journey. I remember one poignant quote to me by a developer when we finished a Product Backlog Item: “Well, we thought that was an 8, but it was more like an 80.” At least we learned a lot of important things.” We don’t estimate side benefits like learning, reuse, inheritance, etc.
We also don’t often factor in bureaucratic waste, which if reduced and even eliminated, would reduce actual time spent working on non-value added things. I once told a senior leader, “You know, if you folks spent more time on reducing waste and being leaner, you’d be surprised at how much faster and more productive we would be.” As usual, I didn’t enhance my friendship, but my job as a Scrum Master wasn’t to make friends (though I concede “friends” are much more likely to do things with you and for you.”)
I’ll share your article with others and maybe my comments can add some value, too. Maybe. Thanks again.
So many great nuggets here, Tom.
> “It is rare that we estimate for our benefit…”
Funny. I can’t remember how many teams I’ve talked with about estimates, and I can’t recall a single one mentioning they do it for themselves. It seems they either estimate for others outside the team or because … don’t you HAVE to estimate everything?
> “Let’s try to keep the time to build and implement something to no more than 2 days of work end-to-end.”
This! This is what I hope to walk into some day. Of course, I might be of little use to such a kick ass team, but the change of pace would be refreshing. 🙂
> “We don’t estimate side benefits like learning, reuse, inheritance, etc.”
Learning. That knocks loose a thought. I see so many teams get confused by story points with consideration of learning. In this context, I’m defining learning as a skill one team member–Sue–is efficient with while another–Bill–is highly inefficient. How can we estimate it properly esp when we don’t know if it’s Bill or Sue doing the work?
These are such tedious and distracting conversations, and I get why Ron feels the way he does. And I’ve seen that sentiment from him as well. I love the dude, and I learn so much from his writings.
By the way, the primary lesson I took away from your comment was Tom should sometimes hold his tongue more often. It sounds like you keep losing friends by speaking truth. Kidding. 😉
Always a pleasure, Tom.
Surely we should not attempt to “estimate followed by develop”. An initial estimate should be accompanied by doing risk/reward analysis i.e., followed by piloting/ prototyping/ wireframing/ POCing/ … This inevitably produces new insights leading to better estimates. Repeat as much as necessary 😁
Joseph, I can’t tell if you’re making a case for better estimates or poking fun at those who attempt to estimate better. Help! 😉
Tanner, our stakeholders need estimates. Agile approaches have a problem there, but it is one we prefer to live with.
Thanks for stopping by, Joe. But I’m not sure I agree.
We need food and water to feed our bodies. We need community and purpose to feed our minds. So are you saying stakeholders need estimates for the work to be completed? Are you certain you don’t mean they’ve grown used to seeing estimates?