Friday, June 27, 2014

Estimate. Or do not. There is no try...

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 this 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.

"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 that's exactly what he was undermining by even asking, "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 the whole team estimates as a group because you want ownership. But it's not permission to be a dumb-ass.  You need to track your estimate and FIX problems with actual vs estimated. And if you can't fix it, then don't ask.

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 your understanding of the associated risks is defined.  If the gap between the fastest and the longest is wide - say greater than 20% of the duration, then you've got work to do.  Any estimate given is likely to be horrible - either risky or inaccurate.

Look at why the spread is so wide and try to eliminate the reasons.  Continuing with the task is super risky until you've narrowed down the range. If you can't narrow it down, then you'll have to live with some risk but it starts by asking the questions and finding out.  Once identified the risk can be called out and a contingency put in place.

Quality estimates are well bounded, showing your certainty. If that certainty doesn't exist, expose it. 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.

In the example above, the spread was 2 days to 7 days.  Clearly something is wrong here. If the lead was thinking that 7 days was right he should have been suspicious of any estimate more than 20% off (around 11 hours).  The developer should have been suspicious of any estimate that varied from 2 days by more 3 hours.  You can see how widely they disagreed.

Their process didn't work because they proceeded with this disparity.  The reason for the process is to identify exactly these types of disparities.  They identified the disparity, then they ignored it.  Their process worked, but they didn't follow through.  This should have been brought up in the retrospective and fixed.

Projects are not well served by either optimism or pessimism.  Projects are served by certainty, and that requires hard work.

See Also:

No comments:

Post a Comment