Planning poker is a consensus-based, gamified technique for estimating, mostly used to estimate effort or relative size of development goals in software development. In this in depth article, you will know all about how to use the planning poker as effective agile estimation technique.
Planning poker is the method of deriving estimate or ‘size of work’ for a task to be completed by a team. It is consensus based estimation technique where each individual, who is part of the team, cast their vote for the estimate. The entire team is collectively responsible for the final estimation. The planning poker is typically used in (but not limited to) software development project with using agile methodologies like Scrum and extreme programming.
Planning poker was first designed by James Grenning and it made popularize by Mike Cohn who also trade mark the phrase Planning Poker.
Here is link to PLANNING POKER - THE ORIGINAL PAPER by James Grenning.
Rand Corporation research in the 1940's showed clearly that humans are not good at estimating hours and practical experience repeatedly confirms the research. Humans are bad at estimating the work as the complexity of the work increases. Also, tracking human time is practically hard.
The estimates derived using planning poker method are relative estimates. They are not precise or absolute estimates. In case of relative estimates, you should not consider it as concrete number in hours but it is just relative size of work considering risk factors, uncertainty, complexity etc.
Software development is not like building a house with finite, well understood tasks and little variation - it is a wicked problem - trying to solve the problem “unpacks” the challenge and reveals more complexity. Typically, in software development projects hosts hidden complexities which don’t become visible, until someone goes ‘in the weeds’.
User poker cards for planning is a variation of the Wideband Delphi method. It is most commonly used in agile software development, in particular in Scrum and Extreme Programming.
Planning poker technique for estimation is not a totally new concept. The roots of this technique are from age old estimation method call Wideband Delphi. This is concusses based methodology.
This technique can be used for the estimation of almost anything where the estimation is based on different variables. Let’s say, if you want to estimate what is the stock market look like by tomorrow end of day or what will be the population of a country next year, you can gather a panel of handful experts on these topics and ask them to provide their individual estimate based on their expert judgement. Off course there are chances that all of them may not provide the similar estimates. Then ask them to debate on their estimate and justify with logical reasoning to support their own estimate. After a round of debate let them re-estimate based on new knowledge or learning they may have got during the debate. At the end the panel need to final estimate as a team and present it. This final estimate will be based on the consensus of an experts of panel.
Also, points to remember is any estimate is at the end of the day is just an estimate based on available facts, historical data and expert judgement. Any estimate may vary with the actuals. A retrospective analysis of variance between estimate and actuals can provide inputs for estimation of similar work in future.
While estimating the target should not be to estimate with hundred percent accuracy but it should to be to provide relatively accurate estimate based on available resources and information.
Planning poker can be played for estimation of stories at any time during either the product backlog refinement meetings or the sprint planning meeting.
One story can be evaluated multiple times as and when needed. If the story is estimated at a higher estimate then it needs to be split into multiple smaller stories and then each of those stories are estimated using planning poker.
When all the members of the development team of a Scrum team are co-located at one office place, it is always recommended to use physical planning poker cards for estimation. Typically team members sits around a table while playing the planning poker.
Physical planning poker card deck contain some special planning poker cards as below:
But today’s Scrum teams are highly distributed. There are many advantages of onshore-offshore model for a typical software development project. In case of distributed Scrum teams, there are obvious challenges in using physical poker cards unless all the team members are in a video conference. To overcome these challenges, there are many free and paid online planning poker tools available in the market. Each of these tools have their own advantages and drawbacks or pros and cons. Following are some of the widely used online planning poker tools:
planningpoker.com
agilebin.com
planitpoker.com
Pointing Poker
votingpoker.com
zentao.pm
JIRA ad-ons
Scrum Poker for Jira app
pokrex.com
scrumvee.com
pointingpoker.com
Planning Poker mobile app
https://www.storyestimate.com/
Firepoker.io - Agile Planning Poker® built with Firebase and AngularJS
Following are the characteristics of good online planning poker tool.
Pre-requisite for playing planning poker- in order to do estimation using the planning poker, each member of the development need to hold either physical planning poker cards to use online virtual planning poker cards.
Stories are estimated using planning poker method typically during the story refinement meetings or sprint planning meeting. The product owner present and explain the story to be estimated. The team members asks questions to clarify their doubts. Once all the development team members are ready for voting, each one selects a card with a story points. At the moments the cards are kept upside down. Once all development team members select their cards, they all reveal their cards at the exact same time. If there are any differences in the votes then the lowest and highest voters explain their reasoning behind the votes. Typically after a quick discussion the story is re-voted. This process is repeated until all the development team members agree on a single estimate for the story.
For a new team, the team can start with affinity estimation technique before using the planning poker.
Since story estimation is a relative to all stories in the product backlog, so you choose the most simple one say A and give it a story points of 2, then the next story if its more complex than A give story point of 3 or 5 depending upon how more complex, more impact the story has. If it is less complex then you can move down to give it a story point of 1 to the next one.
Once the stories are committed in sprint planning meeting, then the development team member create tasks under each stories come up with the plan to deliver the committed stories in a sprint. These task typically not more than one day, typically less than 8 hours. The tasks are estimated in hours.
The reason to use poker cards for planning is to avoid the influence of the other participants. If a number is spoken, it can sound like a suggestion and influence the other participants' sizing. Online poker cards for planning should force people to think independently and propose their numbers simultaneously. This is accomplished by requiring that all participants show their card at the same time.
At the estimation meeting, each estimator is given one deck of the cards. All decks have identical sets of cards in them.
The meeting proceeds as follows:
• A facilitator, typically the Scrum master, facilitate the backlog grooming or planning meeting.
• The Product Owner provides a short overview of one user story to be estimated. The team is given an opportunity to ask questions and discuss to clarify assumptions and risks.
• Each developer selects a card representing their estimate for the story. During discussion, numbers must not be mentioned at all in relation to feature size to avoid anchoring.
• Everyone shows their cards simultaneously.
• People with high estimates and low estimates provide their justification for their estimate and then discussion continues.
• Repeat the estimation process until a consensus is reached. The developer who was likely to own the deliverable has a large portion of the "consensus vote", although the facilitator can negotiate the consensus.
• To ensure that discussion is structured; the facilitator or the product owner monitors the time spent on discussion.
Principles of estimating story points using planning poker
1. Estimation is performed by the people who will do the work, usually in sprint planning meetings just prior to the start of a sprint.
2. Estimates are qualitative, not quantitative. People are much better at comparing things than they are at abstract guesses like "number of hours". So estimates are done using points or some label indicating relative size.
3. The entire team agrees on the story points of each story.
4. Agile prefer relative estimation versus absolute estimate.
Estimation criterion for sizing work do not change much between agile methodologies and waterfall; but the work breakdown, method of estimation, unit of estimation, absolute versus relative estimation technique changes significantly.
Following criterion need to be considered while estimating. This list is not exhaustive and catch all but just provide few of the commonly used criterions.
What to estimate? Size of problem or time to solve problem?
If we know how much time it will take to solve problem then there is no harm is estimating in days or hours. But we are talking about complex domain and also team to estimate so it will be difficult and in order to estimate in days we may need lots of input. Then what?
Think about sizing problem in the basis of some factors like gravity of problem, requirement clarity and technology complexity etc.
Since we are talking about estimating size of problem then let’s discuss about technique again. Sizing problem in hour not feasible so we need some other technique and relative estimate becomes very handy here. Using story point, complexity point or use case point etc are useful technique. Since team prefer writing PBI (Product Backlog Item) in form of User Story so story point becomes popular else you can even think about complexity point or use case point as well if you are using other format for writing PBIs.
But still our sponsor/customer/business wanted to know when they will get full product even before team start working on 1st PBI so what to do?
How to pick reference story point for a new team?
A new team can start with following scale
Small
Medium
Large
1. Pick a "medium-ish" story to be your baseline as a "2". It doesn't matter how long this story might take. It's all pretty arbitrary at this point.
2. Have the entire engineering team point the rest of the stories relative to this baseline story. I like using the 1-2-4-8 scale. "1" is half as complex as "2". "4" is twice as complex as "2". An "8" is another way of saying "this story is too big, please break it up".
3. If anyone strongly disagrees with the points assigned, make sure you talk it out. Perhaps there are hidden complexities that the rest of the team isn't aware of.
4. Over time, the team will get better and better at estimating.
Following are the key differences between Scrum and Kanban teams in terms of estimation.
Take care of the following points while playing planning poker for agile story point estimation.
Wikipedia defines cognitive bias as below:
“A cognitive bias is a systematic pattern of deviation from norm or rationality in judgment. Individuals create their own "subjective social reality" from their perception of the input. An individual's construction of social reality, not the objective input, may dictate their behavior in the social world. Thus, cognitive biases may sometimes lead to perceptual distortion, inaccurate judgment, illogical interpretation, or what is broadly called irrationality.”
It is very important that all the players reveal their voting cards simultaneously at the exact same time. This is to make sure that any one player is not influencing the thought process of other players. By looking at the other player’s votes one may get biased. Typically in a Scrum team the, senior members or old timers in the team can come to their vote conclusion quickly compared to few other members, in that situation their vote can influence other members. Also, the more experience members can rate the story lower points as compared to newer members but the resulting vote at the end represent the team vote not an individual vote. It is very important that the each member of the Scrum team arrive at their vote independently and he or she should be able to justify it with their own thought process. This is to make sure that nobody influences one’s opinion.
Newbie ask question, one story point is equal to how many hours? There is no relation between story points and hours.
Those who actually could do the work are the ones that vote.
When there is a tie in the voting between two sizes which are consecutive, just pick the larger size and move on. Remember, consecutive sizes might be 5 and 8 if you are using the Fibonacci sequence for sizing (1, 2, 3, 5, 8, 13). No one should complain about using the higher number and an equal split usually takes a long time to resolve. It also usually resolves to the higher number, at least in my experience, so let’s use those facts to our advantage and move on.
Use a timer of some sort to limit discussion. This is self-explanatory. I usually like to limit discussions to no more than one minute.
Have the person creating the user stories meet with QA and Development teams prior to playing planning poker to make sure the user stories have answers to the most obvious questions the team will ask. This allows the team to focus on the size, not spend time gathering information.
It will be misuse of estimation to use it for tracking the progress of the work within the sprint. You will need to let go the tendency to micro manage. In an ongoing sprint, saying that ‘as per your estimation, this task is of two days, this task should have been completed by now, why it is still going on?’ is micromanaging. Estimation is just used to plan the work in the sprint. Once the sprint starts, then the work will take its on course of action. Do not try to fit the work in the estimates. Actuals will hardly match with estimates. Instead of using estimates to track the progress of the sprint, use sprint goal. As long as team is committed to achieving the sprint goal, then it is making progress in the sprint.
To steer the team in right direction, focus on the commitment and not the details of estimation.
Fiviza LLC
6010 W Spring Creek Pkwy Suite 362, Plano, TX 75024
Agilebin is the product of Fiviza LLC.