Estimate Story Size by Playing Agile Planning Poker
Developing Accurate Effort Estimates By Playing Games
The poker player learns that sometimes both science and common sense are wrong; that the bumblebee can fly; that, perhaps, one should never trust an expert; that there are more things in heaven and earth than are dreamt of by those with an academic bent. (David Mamet)
If you’ve read my previous post (recommended so that the following will make sense) you now have a mechanism for sizing the Effort of your Stories. But how do you actually come up with the numbers for Complexity and Size? Over the years that I’ve been leading software development projects, I’ve used a number of methods including comparison of projects of similar size and complexity, Microsoft Project, Function Point Analysis or even simply guessing. There have been a few other trendy and perhaps oddball approaches thrown in for good measure. Curiously, regardless of method, the results have tended to be pretty much the same. There has, however, been one exception. I’ve gotten noticeably better results with Agile methods using Agile Planning Poker. Poker? Yes poker – well not really poker. It’s actually a process that is gaining in popularity as a means for sizing Agile Stories.
Agile Planning Poker is generally attributed to James Grenning in 2002 and popularized by Mike Cohn, owner of Mountain Goat Software in his book Agile Estimating and Planning. The process involves the members of the team independently developing quick Effort estimates and then comparing their estimate, discussing the differences and arriving at a consensus based on the discussions. Their independent assessments are all shared concurrently with the group by holding up flash cards with the numeric values of their respective assessments. The process relates to the game of poker only in the sense that the participants make their assessments discreetly, concealing them from the other participants until they all show their hands together. It is Important to the process that the participants conceal their assessments from each other and all participants reveal together. While this may seem silly, it serves the definite purpose of having each person arrive at their own conclusion without being influenced by the thinking of other members. The process is quick, simple, and in my experience, very effective.
The role of the moderator in this process is essential. The moderator sets the tone and the pace for the discussion. The moderator is typically the Project Manager or Scrum Master. The moderator:
- Reads the stories.
- Maintains pace to make sure that the process does not bog down.
- Moderates discussion, tempers the naturally competitive nature of some to ensure that nobody dominates with their perspective and that people who may not normally voice their opinions are also heard.
- Maintains a focus on good results – not on individuals having the winning hand.
- Ensures that people do not cluster their estimates. Some team members may want to be seen as correct, or at least not too different from the pack and always cluster their results in the middle i.e. always guessing 3/3. If your results follow a standard Gaussian Distribution, your safest bet would always be 3/3 if your motivation is to be with the pack, or to be viewed as being correct. Remember that although you are hoping to have a Gaussian Distribution, it is neither your motivation nor that of the team. What you are really doing with this exercise is trying to discover the outliers – the Stories that are actually much larger or much smaller than originally thought when the Story was first written. Following the herd will not uncover the outliers and consequently you will be exposing your project and team to risk. The Moderator must watch for this behaviour and encourage different viewpoints from all team members to make sure the outliers are uncovered.
- Helps the team to avoid Groupthink. If everyone always agrees, then you can be almost certain that you are doing something wrong. Diversity of opinion is essential and it must be encouraged. If there is too much consensus, the moderator should play Devil’s Advocate to stimulate alternative thinking.
Often it is only the developers involved in the sessions, but I like to have the Product Owner involved. At a minimum, a Planning Poker Session should include all of the developers on the team. For several reasons, it is a mistake to leave this work to a few of the senior team members:
- Smaller groups are more likely to have a group biases that can become Groupthink. More people means more opinions.
- Junior or newer team members learn a lot from these sessions. Experienced developers have insight that comes from years of experience and years of making and then recovering from mistakes. This experience is of incredible value to the team as a whole and can help to quickly elevate the capabilities of the entire team.
- Ensures that estimation is not inadvertently biased by the viewpoint, knowledge or experience of any one team member.
- When Product Managers / Owners are involved and participate in the estimation, they gain significant insight into, and a greater appreciation for the issues related to the development of each Story. Similarly, developers gain better insight into the views of the Product Owners. This can be very useful for creating and enhancing good team dynamics and communication.
Some teams use cards with numbers printed on them. This can be particularly useful if you are using the Fibonacci Scaling, but is less important than when using the T-Shirt Sizing (SML) or Scale of 1:5 which I use. I prefer to not use cards because I don’t want to get bogged down at the beginning of a session while people are finding or sorting their cards. It is not a coincidence that I use two vectors and a scale of 1…5 for everything including Ranking of Stories, Defects, Risk and Effort. Simply put, we have five fingers on each hand (at least most of us do), and we have two hands. With no muss or fuss, all team members can walk into a Planning Meeting prepared with all of the tools they need, as long as they can count to five and know which hand is their left hand, and which hand is their right hand. As well, because our result (Effort) is the product of two numbers (Complexity x Size) we keep things nice and simple having nothing more complex than the ten fingers we were born with.
It is up to the moderator to make sure there is no bluffing. Even though this is called Poker, honesty is the rule. It should be no one’s objective to “be right”. Rather, you are attempting as a team to create accurate estimates – not win the game.
The Six Steps
1. Moderator Reads Story Description
The moderator reads the story description to the team.
2. Ask Moderator Questions
The team asks the moderator questions about the Story and the moderator provides clarification about the Story. The moderator makes sure that the questions are relevant to the estimation of Complexity and Size. Q and A should be no longer than two or three minutes. Ideally you want to stay under two minutes per Story.
3. Estimate Cards (Fingers)
The moderator finalizes discussion on the Story and asks each team member to make their estimates of Complexity and Size (see previous blog post for details) and write down their estimates for both Complexity and Size on a piece of paper or on their notepads. Estimates are not to be revealed until everyone has made their individual determinations.
4. Show Hands Simultaneously
Once all team members have decided upon their estimates, the moderator asks the team to hold up their hands with the number of fingers on their hands representing Complexity and Size. For ease of processing the results make sure that the team has already decided upon consistent use of hands for both Complexity and Size. I use the left hand for Complexity and the right hand for size. It doesn’t matter which you choose as long as your team is consistent.
5. Discuss Low / High Estimates
If everyone has exactly the same results (highly unlikely) then there is not much to discuss other than the possibility that there is a groupthink happening or that something is being missed. Assuming that there are differences of opinion, discuss the high and low values for both Complexity and Size. The objective is to tease out the issues that are perhaps not being considered by all team members. This is where team diversity is essential. The broader the range of experience of the team members, the more value there is to the exercise.
6. Consensus or Pessimist Wins
Timebox the discussion and move to a conclusion. You are attempting to gain consensus, but consensus is not always possible. Decide as a guideline how you will deal with situations where you cannot achieve consensus. You really have three options:
- Take the average. I don’t like this approach because in my view it tends to bias the results towards the optimistic view (see previous post) and may lead to underestimation.
- Accept the most pessimistic estimate. This is my preferences as in my experience, estimation tends to be optimistic and to counter that bias, the pessimistic view seems to balance things out. This isn’t a license for the people with a consistent “glass half empty” view to rule the day, but it is a means of counteracting people’s generally, and natuarlly optimistic estimation tendencies. Your team may have a different bias so adjust accordingly.
- Defer discussion to a separate meeting on particularly gnarly ones. I do this as a last resort. I find it is best to keep the estimation in your planning session. If you find a great deal of disagreement on many of the issues, then decide to consistently go with the pessimistic view and then review the estimates in your retrospective. Use that information to recalibrate. I will talk more about recalibration and velocity in my post next week.
7. Finishing Up
Once you have made a decision, write the Complexity and Size numbers in the upper right hand corner of the story card. Multiply the two numbers together. The product will be a number in the range [1..25]. Using the colour coding from the previous post, you now have your estimate of effort. Repeat this process for each of the remaining Stories in your Sprint.
Agile Planning Poker is a quick, simple way to estimate the Effort required to complete your Agile Stories. It engages the team and encourage them to bring into the open issues that might impact Effort estimates that may not otherwise be discovered or considered. With a new team, or when you are introducing this process to your organization, don’t be tempted to size all of your stories right away. For the first two or three sprints, size the Stories in the Sprint you are about to begin. Use your Sprint Retrospective to recalibrate each time until you are comfortable with your consistency. The consistency is important because it will be the basis for calculating Velocity – more on that next week.
As usual, I look forward to your comments.
Old card players never die, they just shuffle away. (Author Unknown)
I am an independent consultant who has been leading software teams, designing, building and delivering software for nearly three decades. It’s still as exciting and enjoyable for me today as at was when I wrote my very first Hello World program and saw it spring to life in front of me.
JésicaOctober 25, 2010 at 2:43 pm
Hi Michael, I really liked your post. The description was clear and concise.
I have a question for you,about moderator role: He just should read the story to be estimated, answer questions and have a control of discussion time?. He actually doesn’t participate (by voting) in estimating rounds. Is He the responsible for acting (I mean: deciding) in case of getting stuck in a tie?.
MichaelOctober 25, 2010 at 4:11 pm
Thank you for your comments.
Yes, you are correct. The moderator remains neutral during the discussion so as to not unduly influence anything in the process. The moderator, however, makes sure that no one else dominates the process, and ensures that everyone has a voice. The moderator votes only when there is a tie to be broken, or in the case of a genuine impasse, defers discussion on that particular item into another meeting for a more in-depth review.
Project Estimation: Mapping Size and Complexity | pmStudentSeptember 14, 2010 at 8:40 am
[…] you are new to planning poker, there are many great resources available to learn more about […]
Estimate How Long It Will Take To Complete Your Agile ProjectAugust 1, 2010 at 10:16 am
[…] the concepts presented in my four most recent articles: (Estimating Effort For Your Agile Stories, Agile Planning Poker, Calculating the Velocity of Your Agile Project) Using these articles as the platform upon which we […]
Joe CarusoJuly 24, 2010 at 11:10 am
You mentioned in the above to have read a ‘previous’ post – can you confirm the title?
Finally getting around to reading your articles. I hope to get through all of them and perhaps play arm chair quarterback on the project I am on now, which I inherited after planning was done and was way off to put it mildly.
Interestingly, while we started off as a ‘Project – Large’ formal methodology at my company, we morphed into Agile otherwise we would never ever have hit our milestone last week, or the two coming up.
Thanks for posting.
MichaelJuly 24, 2010 at 11:33 am
Thank you for your comments. I’m sorry for the ambiguity. Here is the previous article: Estimating Effort For Your Agile Stories I’ve also updated the story to include the link. The articles have been written somewhat as a series with many of the articles building on concepts from previous articles. I think you will find it more effective to read them in chronological order starting with How To Make Your Project Not Suck
It’s interesting that you changed methodologies mid-stream. I would really like to hear more about how the transition was managed.
I hope that you find the balance of the articles useful.
Calculating The Velocity Of Your Agile ProjectsJuly 23, 2010 at 12:05 am
[…] Michael Lant Technology Ethos: The Intersection of People Process and Technology Skip to content HomeRecent PostsAboutLinksContactTwitter « Agile Planning Poker […]
Tweets that mention Agile Planning Poker -- Topsy.comJuly 13, 2010 at 5:45 pm
[…] This post was mentioned on Twitter by SolutionsIQ: Agile Planning Poker http://bit.ly/9Gwu6t Just posted my latest entry on Estimating Size of #Agile Stories […]