Estimating projects

Several years ago I told a story about a project that proved that estimation was a waste of time once the work was split up in small enough chunks. Not necessarily equal size of chunks but manageable size chunks. But sometimes you need to do estimations because somebody wants to know the cost of some project or large feature.

When I did that in the past I did not gather the whole team and started breaking down the back log in order to figure it out. or actually I used to, but the process was long and painful for everybody. That is why I started ignoring the team and just gathered a few experienced people representing different skills and did what I called "pull a number out of your ass" estimations. These estimates turned out to be good enough for high level planning. And they took less than an hour to complete. Now I'm happy that somebody have formalized it a little and given it a more politically correct name; Blink Estimation.

Blink Estimation in a nutshell is:
  • Gather some smart people in a room, discuss the problem for a while.
  • Then write down one estimate each and reveal to each other at the same time.
  • Decide on what number to use.

1 comment:

  1. @Craige Boyle: In my experience any process relies on the team knowing what the goal is and the team feeling as if they are part of the process. Putting the team in a room to talk about things far into the future (that may not happen) for a long time does not help the team in my experience. A team is not helped by knowing everything that might happen in the next year. But the team is helped by knowing what the goal is a year into the future and should definitely be part of short term planning and estimation.
    In the article above I failed to point out that when I talk about "project estimation" I'm talking about big things that will take a long time to complete. not the work that needs to happen over the next few weeks or months.