A Beginner’s Guide to Planning Poker
I have written about estimation before. I have written about Planning Poker before. Today I am going to do a simple beginners guide to Planning Poker. The difference is that this guide is meant to be used by you. You could use it as a presentation presenting the idea of Planning Poker. Alternately it can be used to teach a team and run the first session. With that frame of reference in mind let’s get started.
How many of you like to estimate as a team? I do. I find it an easy process with lots of value for everyone involved. What if I taught you a method that will get your team rapidly reaching a consensus while estimating? These estimates will be accurate enough for iteration planning. As a side benefit, the team will have a better understanding of the product and its future direction. The process is lightweight enough to keep the team engaged. The end result is estimation meetings that are not dreaded by anyone.
Estimation is an interesting beast in project management. It needs to be done if there is any hope of creating a solid plan. Spending more time on it doesn’t mean more value. Truth is we’re pretty bad at the whole process. The answer I give you today is Planning Poker.
Estimation does not have to take a long time. It has been found that 80% of effects generally come from 20% of causes. That is, if we spend 10 hours estimating the first 2 will be where 80% of our effective work is done. What we take from these numbers is that as the estimate gets more precise extra time spent on refining it further is subject to diminishing returns.
The whole process of getting estimates is difficult for us. Imagine a jar filled with sunflower seeds. How many seeds are in the jar? The guesses will likely have a very wide distribution. Now imagine a smaller or larger jar next to the one we’re guessing on. It is also filled with sunflower seeds, but the quantity inside is labeled. Now how wide do you think the distribution will be? This is simply absolute versus relative estimation. We’re bad at absolute, but pretty good at relative.
These issues can be addressed with Planning Poker. Planning poker is a tool for estimation. It works best for requirements but can also be used for tasks. It can be used in many different project settings but works best in Agile settings. The “Poker” part of the name derives from using special playing cards in the process. The idea is that the right people come to a consensus on approximately how large a requirement is or how long a task will take. This discussion leads to better understanding of the product by the team.
The planning session should involve the person that can best explain the requirement/task (item) and the people who will be doing the work to complete the item. All of the people, even if on different teams. Every person that will be doing work on an item is given a set of cards. On the cards will generally either be a modified Fibonacci sequence, or a set of non-numeric sizes.
Each item will be introduced and given a brief explanation. The team will then have 5 minutes to discuss and ask questions. At the end of 5 minutes all team members that will do work on the item place one card face down in front of them. The card represents how much work they think needs to be done on the item collectively by all people who will work on it. If they all match, that is the estimate and the team moves on. If they do not match the outliers explain their case, ask questions, and a new round of putting cards down commences. This should be limited to 5 minutes as necessary. In some cases a team may have a rule allowing for some dissent in the consensus to prevent deadlocks.
The modified Fibonacci sequence is usually something like 0, .5, 1, 2, 3, 5, 8, 13, 20, 40, 100. These numbers are not hours. They are relative sizes. Sometimes a deck will be laid out with XS, S, M, L, XL. These would roughly match to 1, 2, 5/8, 13, 20. The idea is that there are previously completed items that the team decided represent various values in the deck.
The item being discussed is effectively compared to these reference items for overall difficulty. This makes the estimate a relative estimation and not an absolute estimation. Because the estimate is relative it is more accurate than a similar item would be if estimated on an individual absolute basis.
The process is largely driven by the team discussion the item. When they disagree on size they learn from follow-on discussion as well. The result is a better end-to-end understanding of the product by everyone in the meeting.
The spacing of the sequence used in estimation is designed to save time. The value derived from knowing a task is slightly harder than one that took a week is significantly lower than the value of knowing that a task is slightly harder than one that took 4 hours. As requirements get more complex it will take longer to get an exact estimate. For most planning the spacing allows for best value, providing for planning without detracting from available time for work.
Estimation will never be an exact science in software development. It will always be difficult. There are tools that can help. One of those tools that has proven effective for many teams is Planning Poker. The process is easy to learn and master. The value lies not only in the estimate for planning, but the product understanding by the team. Estimation doesn’t have to be a four letter word. Stop doing what doesn’t work and try something new. You could start with a game of poker.
Quick footnote: I think I’m going to create a slide deck to go with this. At the very least a series of pictures and a downloadable card template. Check back this weekend.
