Search This Blog

Monday, February 22, 2010

Planning Poker

I have been using planning poker in our planning meetings for a while now and I get many people asking what it is and how does it work so I thought to write my expericence with planning poker.

Planning Poker is a technique used in agile software development for estimation. There are various ways it can be done but the most effective way is to do it with a cross functional team.

Before you start the estimation make sure you create (or bring an existing one) a user story, user story should be very small (possible independent from other functionality) and self explanatory, we do not use any fancy system to record user stories, in fact we use one of the oldest method ... on cards. The goal of this planning meeting is to estimate that user story.

In our work environment we use a cross functional team, we do not start estimation if we do not have at least one person from QA, development and BA team. The advantage of this mixture of skills is to be able to see the user story from each angle. BA usually kicks of the estimating meeting by explaining the user stories, depending upon the story other teams members may have questions like, what technology it will be developed in? Will there be any automated test? Etc.

Each member in the planning meeting is given a series of cards; we use 0.5, 1, 1.5, 2, 3 and 5. You can use any units you want, the units can be related to days, hours or some fictional units (some agile practitioners like to call them relative units of work).

Once the BA has explained the user story and everyone has asked their question, each of the team member picks one card from his/her deck. They do not show the card until everyone has finished picking their number, on one go everyone then displays the card. Most of the time the estimates from all of them will be within a small margin let’s say 2.5-3.5 in this case you can safely assume the estimate to be 3.

If for whatever reason the estimates are very different like one person is 2 and other person is 5, both that person gets the opportunity to explain their estimate, it may happen that the person with estimate 2 has some insight on the problem, it may also happen that the person with estimate 5 raises a very valid problem, based on the argument presented by all the parties you may play the estimate game again.

No comments: