Estimate. Or do not. There is no try…

You know you’re in trouble when you paraphrase Yoda

I talked with a technical lead last night and it was fascinating. He said, “You’re suggestions for estimation don’t work.” He was referring to the several posts I've made on my blog and in emails about estimating.

He continued, “I asked one of my guys for an estimate, he said 2 days, I said 7 days, it took 6 days. This happens for all our estimates.”

“Why do you continue to ask him for estimates?”

“What?” He looked shocked by the suggestion.

“Why are you asking him if he obviously can’t estimate?”

“Well, we want his buy in,” the technical lead was adamant.

I could see he just wanted what was best for the team, but tried to explain how he was undermining his own team by continuing to ask for estimates.

“The crazy one here is you. You keep asking him and you know he can’t estimate. Don’t ask him. Why do you want his buy in if you know he’s wrong (by a lot!)? Are you trying to teach him how to give shitty estimates? Stop it.”

Agile has this notion that it’s best to estimate as a group to get the collective wisdom of the team. When the backlog items are estimated they have not yet been assigned, they are owned by the team. But desiring collective ownership is not permission to be a dumb-ass. You need to track estimates and FIX problems which lead to habitual differences between actual vs estimated. And if you can’t fix it, then you should stop wasting time estimating.

I’m an advocate of asking two questions for every estimate, “what’s the longest this could ever take?” and “what’s the fastest this could ever be done?” The purpose of these questions is to show how well defined is your understanding of the associated risks. If the gap between the fastest and the longest is very wide — say greater than 20% of the duration, then you've got work to do. Any estimate given is likely to be horrible.

Look at why the spread is so wide and try to eliminate the reasons. The task is super risky until you've narrowed down the spread. If you can’t narrow it down, then you’ll have to live with some risk but start by asking the two questions.

Quality estimates are well bounded, showing your certainty. If that certainty doesn't exist, expose the uncertainty. If the problem is that your developers use optimism to lie, then expose that. Hold the developer accountable for their shitty estimates — optimistic or pessimistic. Optimism is just as dangerous on a project as pessimism. Projects are not well served by either optimism or pessimism.

Projects are served by certainty, and that requires hard work.