Estimate Story Size by Playing Agile Planning Poker

Developing Accurate Effort Estimates By Playing Games

Background

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 Process

The Moderator

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.

Participants

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.

The Tools

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.

No Bluffing

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:

1. 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.
2. 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.
3. 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.

Conclusion

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)

Michael

Michael

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.