Software Best Practices

I've been an advocate of Steve's approach to the management of software development for a while now and have just started reading the Software Estimation book. Looking around the internet at tools that are available I came across this little website (http://www.planningpoker.com/) and would be curious to know what others think of this approach to estimation as a contributor to the whole effort. I don't think it can work entirely on its own, but there appears to be some merit in its use, if for no other reason than to make the project team members and/or stakeholders feel they have involvement and a valid forum for contributions to the project.

 Steve Huckett 

Planning poker is a fun and simple way to implement a Delphi process. As a Delphi method, it is useful when there is very little data and large uncertainty. This works well for the Agile world since, by definition, we have not done the work to lower the uncertainty at the point the planning poker is played.

The point of any Delphi process is to bring in as much information as you can from multiple sources in a short period of time. By forcing each participant to "disclose" their estimate at the same time, differences are disclosed and can be discussed.

Of the clients I have that use planning poker, the stakeholders don't normally get to estimate. However, when they watch, they understand better why the estimate came out the way it did rather than a dark, mysterious process.

Planning Poker is an interesting approach to a Delphi-type estimation process.  As Earl points out the strength of the Delphi-type processes is that you get multiple independent inputs (and get them talking to each other) in a relatively short period of time.

The big drawback that I see to PlanningPoker.com's implementation of a Delphi process is that they are generating "point-estimates".  They are not using ranges for their estimates.  While there are several ways to go from a group of folks giving point-estimates to ranged-estimates, it really is better to start out with people giving ranged-estimates.

One reason is that the range tells you a bunch about the estimator's uncertainty.  If Bob thinks that the Foo-task will take 10-40 person-days of work and the Bar-task will take 35-40 days of work and you ask for point-estimates Bob is likely to tell you Foo = 40 and Bar = 40.  The relative uncertainty has been completely obscured.  Those point-estimates also feel a lot like commitments after the fact.

While I like the tool, I'd like to see it implemented where you pick both a high and a low card to represent you estimate range.

You raise a very valid point/issue there. The need to express uncertainty and even outright doubt that the project or work package can be achieved. Certainly a relevant expression of those involved in estimating in the early stages of a project. I have some developers who are reasonably confident in what they do. That of course brings its own dangers into the estimating process (!), but they may typically want to point estimate. Others I know will always want to paint a worst case scenario and yet others will be happier wanting to give a range of values. I guess ultimately it is the skill of the dealer (a.k.a. the Project Manager) to determine the balance. Definitely something to add to the toolbox, but perhaps using estimation "cards" of our own design rather than some online facility.

I guess the important thing with this tool is to iterate the process - it isn't a one hand game! That way successive revisions of the estimation process should/ought to narrow the inherent range of estimation values down collectively. That must be better than an enforced estimate determined by the PM, as ultimately you want to be sure that the team come with you and don't cry foul or cause waves later on in the development lifecycle.
 

Steve Huckett
 

Iterations provide great feedback to the estimators, so they get better.  

As far as single point estimates, keep in mind that Planning Poker is mostly associated with agile, where single point estimates would be ok.  This is especially true when it is used for iteration (Sprint) planning.  They are using it to estimate stories that will be completed in that iteration. By that time the stories are typically decomposed, so the typical estimate is for at most a few days, not 10-40 staff days.  In other words, they are well down the cone-of-uncertainty where the relative uncertainty is pretty low.

Having said that, I believe that Planning Poker could be used to estimate further out.  In that case, I would expand the game to get Best Case - Expected Case - Worst Case estimates.