Estimating in a vacuum

This week I’ve mentioned several big errors in the estimation process:

  • Poorly choosing the three points in a three-point estimate (minimum, most likely, maximum)
  • Not updating estimates frequently throughout the project as new information is revealed
  • Not having the person who will do the work provide the estimate for that work

To the list above, let me add this problem with estimating that leads to big estimation errors:  estimating in a vacuum.  This is really the same coin as the last bullet point, only I’m looking at it from a different side of the coin.

I’ve been on many, many projects where it’s my responsibility to create the estimate for the IT-side of a project (in my world, there is a business partner who estimates the resources needed from the business-side).  Generally, I have carte blanche to create what I think are the resources I need to get the job done.  Whenever possible, though, I like to bring my development team into the effort of project estimation.  I like to carve up the project into pieces that each developer knows they’ll be responsible for, so they can estimate their respective work efforts, buy-into those estimates, and be held accountable for those estimates.

Another good reason to bring the whole team into the work of project estimation is that it helps to reveal aspects of the project that I, as a project manager, may not fully know about or understand.

Agile project teams get this.  Agile project teams estimate user stories together.  Agile project teams use Planning Poker to jointly estimate the user stories on the product owner’s product backlog — and they know that in the first round, they aren’t likely going to all agree on the number of story points that the user story will require to complete.

I had a mock session of Planning Poker with several IT project managers recently to expose them to the game.  In our mock session, we estimated one user story and the difference between one person and another was huge — like, 90+ story points difference (one person used a card marked ‘100’ and others held up a card with a ‘3’ or ‘5’).  As we talked about the discrepancy, we learned why the person who held up a ‘100’ did so.  Her perspective was enlightening and revealing.  So, even though she may not have been the one to code the function we were estimating for, her perspective would have been useful to the person who would be coding that function (and who would have been playing Planning Poker right along with us if this weren’t a mock session).

Bad things happen when one person thinks they know so much that they can create estimates without anybody else’s input.  It may not always be feasible or even desirable to create estimates in a team setting like an agile team.  But, that is the best way to create estimates.  Tomorrow I’ll share an example of this.

Leave a Reply

Your email address will not be published. Required fields are marked *