Estimate first, ask questions later... or was it the opposite?

April 23, 2015 · Agile Scrum

Do you know Jim Benson's 5 estimation pathologies?

  1. Guarantism – The belief an estimate is actually correct.
  2. Promisoriality – The belief that estimates are possible
  3. Swami-itis – The belief that an estimates is a basis for sound decision making
  4. Craftosis – The assumption that estimates can be done better
  5. Reality Blindness – The insistence that estimates are implementable

In this article called A 6th Estimate Pathology Neil Killick explores a 6th estimation pathology that he named Accepti-ism/Resign-ism:

The belief that, when someone asks me for an estimate, I should simply go off and tell them “how long” rather than ask more questions about the actual information required and the underlying need.

I like this idea a lot.

I got burned recently (again) by listening too much to my techie-heart and thinking too long in the solution space (i.e. torn the problem to pieces in search of a solution). We ended up fighting a lost battle for a very long time. Instead we should have stopped for a while, asked questions, clearly communicated our expectations and then provided various estimates based on the fulfillment of those expectations instead of going for one single estimate right away.

Here's a workflow that worked for us. When asked for estimates, if you find out that providing that estimate does not come easily:

  • Sit back & relax
  • Try to identify the pieces of the puzzle that would be required to provide an estimate
  • Then play with those pieces to provide multiple estimates with / without these information

This process forces you into seeing the problem from multiple angles and compare estimates with one another.

Human beings are way more efficient at comparing than to provide absolute estimates. This process helps refine the estimates you gave by putting them side by side.

Finally it also helps the people you give those estimates to not to run with your estimates right away and treat them as deadlines.

And at the end of the day, if you still don't manage to solve this issue, you can certainly fall back to what Neil described: be honest about the uncertainty of your estimate and provide a clear strategy how you intend to learn more about the issue. But there's a lot of possibilities before resorting to this, don't you think?

Comments powered by Disqus