Agile: Planning Projects with Poker and Pi

Plan-Do-Check-Act is the key learning cycle that is at the foundation of lean thinking. But how do you make a good plan, and more specifically, how do you estimate how long the tasks in the plan will take?

If you have historical data, or you can accurately estimate the work content, the task of estimating task duration is very straightforward. But if you are doing something you have never done before, estimating the task duration can be very challenging.

Fortunately, agile project managers have developed a clever approach for this very challenge. It is called project planning poker. It was developed to address the challenging problem of estimating how long it will take software developers to complete coding tasks. Here is how it works: 

Step 1: Each of the developers is given a set of Project Planning Poker cards (see Figure 1).

Step 2: The task whose duration is being estimated, is discussed.

Step 3: Each participant privately selects the card which represents their best estimate for how long it will take to complete each task.  

Step 4: Participants reveal their choice for the task. If consensus is reached, they record the result and move on to the next task. If consensus has not been reached, they discuss and try again.

Project planning poker cards. Project planning poker cards.



The elegance of this approach is that it is fast and easy. It harnesses the wisdom of the participants. It is based on relative measures, i.e., a task that is given a 40 will take twice as long as a task that is given a 20.  (The absolute duration of each task can be determined by actual data. That is, teams will need to record how many points they estimated for each tasks and then measure how long each task took. A conversion factor between points estimated and actual task duration can then be constructed.)

Agile project managers have found this approach to be helpful because they are constantly asked to estimate how long it will take to do something they have never done before. And lean practitioners are often faced with that very same challenge. They may need to estimate how long it will take to dramatically improve a production line’s layout or develop standardized work to enhance patient flow or complete a kaizen newspaper item. In each of these cases, there may be very little historical data to estimate the task durations. But, an agile approach may be exactly what you need.

There are 2 Comments

drmike's picture

Chris, an excellent question, and you are on the right track. With project planning poker cards a team can arrive at a good estimate of the relative size of the tasks but not a good estimate of the absolute size of the tasks.

It may seem crazy, but it may actually be the most sensible approach. Here's why: Usually it is a lot easier to estimate relative sizes than absolute sizes. That is, I could probably easily tell you when half the yard was raked, but it would be much harder for me to tell you how big the yard is.

So when agile folks use planning poker cards, what they are doing is assigning "points" (i.e. the value on the card) to each task. If the team has done this before, they should have a good idea of how many points they can do per hour. So for example, if I were to estimate how long it would take me to complete all my to-do's from my significant other for a given Saturday, the total might add up to 5 points. Which overall sounds very doable, except I then realize that based on historical data, my velocity is usually 1/2 point per hour, so I will need to plan on 10 hours of chores.I could use the same historical velocity information to calculate the expected actual duration of each task.

If I don't have historical velocity information, I could guess what my velocity will be, that may work, but I would also recommend closely monitoring the actually duration of the early tasks in order to firm up my estimate.

Chris G. Chatzopoulos's picture

Poker & Pi is a very funny and clever with high convenient performance managerial method. I like it a lot. :)
I would like also to make a question about the time estimation of a Project. After the execution of the Poker & Pi procedure, each task is characterized as small task or, medium sized task, or large, or tiny, or huge e.t.c according to the table above. Right? Project Managers usually seek for exact time duration for each task. Is there any way of interpreting the afore-mentioned characterizations (tiny, huge e.t.c. task) into an exact or a close enough time duration for each task?
As an Example, if we assume that a whole Project should be accomplished in six months. So, the interpretation of each characterization should be in accordance with the six months, so a huge task is about to 4 months, a very large tasks about tp 3 months, a large task about to 2 months, medium about to 1 month, small about to 14 days and tiny about to 1 week? Does this thought step onto the right direction or not? Is Poker & Pi mostly an abstracted method rather than a strict one?