Sucesssive Planning Poker

While I think planning poker is an excellent way to estimate any software delivery work, I've noticed that actual development work is sometimes started to soon, supported by a backlog and release plan that are made up of largish items (12 - 20 ideal days)

While agile methods espouse getting started as soon as possible I think a little more up front analysis can actually help reduce rework and eliminate ambiguaty.

I've come up with something I call Successive planning poker. The premise is simple

1: Conduct an initial round of planning poker

Frequently the estimating group groups will often end up with lots of items that end up with big estimate ranges. (ie 10 ideal days +) Large estimates represent work that is not well understood, contain many assumptions, and are riddled with unknowns.

2: Conduct analysis and research activities necessary to resolve ambiguities in any large estimates

During the initial planning poker session make sure to keep careful track of ambiguity and uncertainties that could be resolved with a reasonable amount of research. Because the group doing planning poker is cross functional, they should be skilled to answer questions ranging from existing legacy functionality to product limitations to existing business processes or policies, etc,. Give team members a day or two come back with answers.
3: Conduct a successive round of planning poker

Go through each largish estimate from the initial planning round and use the answers and research completed by the team to break up the work items into smaller, more manageable pieces and estimate these pieces independently, hopefully ending up with work items ranging from 1- 8 ideal days.

4:Repeat

Repeat successive rounds of estimating and researching until you have a quality backlog of items that are reasonably fined grained enough to tackle within an iteration in a reasonably predicable manner.

While the above approach might be obvious to some, I've been on several projects where we didn't do this an the first few iterations really suffered, of course a couple iterations of development really did alot to smooth out future iteration. Still I think just a little but more planning dillegence (done in a collaborative and cross functional way of course) could have helped to gain the same information faster and far easier.