We all know the challenge of estimation. For agile teams this is especially true as it’s all about small teams building high quality software according to aggressive milestones. Accurate estimating is a critical building block to achieving agile objectives (in fact, LiquidPlanner counts many agile teams as customers).

Planning poker was popularized by Mike Cohn in 2002 as a consensus-driven estimation technique. The “game” is based on a list of features (or “stories”) to be delivered and a deck of cards that represent units of time. A moderator is chosen to administer the session, features are described in terms of scope, and then team members simultaneously turn a card over that represents how long they think a given task will take. If everyone is on the same page, take one step forward! Mark the estimate in the schedule and move on to the next task. If estimates diverge, then the developers are encouraged to discuss their different estimates in an effort to gain consensus. They then choose a new set of estimates, select new cards that represent a revised estimate, and then reveal them once again to the group. Wash, lather, repeat.

This is essentially an analog version of what LiquidPlanner provides with ranged estimates (one that unfortunately requires the entire development team to take valuable time away from actually developing software). Ranged estimates obviate the need to drive consensus at a macro level because each task owner is liberated from having to come up with (i.e., guess) and stake themselves to a single number. Rather, if there is a great deal of uncertainty around a specific task, they simply reflect that in their range. Since all of the other team members can see one another's estimates within the application itself, there is room for a dialogue as to what is and what is not realistic in terms of estimates. As work is completed on a given task, a developer can simply reduce the range to express that there is less uncertainty and the entire plan is then rescheduled accordingly.

Planning poker is actually a great idea for a bygone era — it succeeds in bringing all project constituents to the table (literally) to achieve consensus. It can work well for making estimates at the inception of a project but as we all know, those best guesses are just that — guesses. Most of the time, we don’t really have a good idea for how long something will take until we actually begin the work. Specifications change, obstacles arise, sh*t happens. Of course, because so many companies these days rely on offshore developers to build their products, it’s even more difficult to bring all parties to the table. In any event, unless you intend to play planning poker every day, this methodology is not truly sustainable. At least not in a true agile environment.

--------------------------------------

Robert Nachbar is the Principle of Kismet Communications, a Seattle-based public relations consultancy that works with technology start-ups. As the result of his work with LiquidPlanner, Rob has developed a surprising interest in all things project management, so much so that he is occasionally compelled to blog on the topic.

Original post from LiquidPlanner Online Project Management Software