Skeptek.com

The agile project management technique of planning poker is a popular estimation process for software development.  My favorite Agile author Mike Cohn presents a good description of the practice on his blog here: http://blog.mountaingoatsoftware.com/?p=14. 

Let me start off by saying that I really like planning poker.  It’s a very clever way to estimate user stories.  However, from a tech startup standpoint, where time is a critical resource, planning poker becomes a non-essential part of the agile process.  Here’s why:

• The cost is material.  My typical 2 to 3 week iteration has approximately 40 stories.  I find that it takes between 2 to 5 minutes per story.  Using 3 minutes as average, that brings us to 120 minutes.  So my team of 10 people, spend 2 hours in planning poker.  Multiply that by $75/hour and you get a cost of $1,500, not to mention the opportunity cost of not coding.  At a startup, where time is so valuable, this is a tough pill to swallow.
• After several iterations and planning poker sessions, I began to realize that I could estimate just as good as the developers.  I would compare actual hours reported by my developers spent on user stories to the story points estimated and calculated that my estimates had the same standard deviation as the whole team did the estimation.  Even if you continue to practice planning poker, this is an excellent exercise to refine your estimating skills.
• Take shortcuts.  The average bug tracked in our bug tracking software is about a 1 story point.  Skip estimating every bug and just apply this average. 
• If deadlines are less critical to your particular situation, then why care so much about your estimates?  My web application dev team often has a release plan that changes every couple weeks.  We are not tracking a burn down to know when the release is complete, because the story make-up of the release changes so frequently.  The burn down chart is not actionable for us. 

On particularly large stories or Epic’s, I ask the developer who will probably be working on the story to give me their estimate.  But for the majority of user stories, I take care of the estimation.  Maybe you can too?