Q 265. Planning Poker is a gamified technique for estimating, more commonly used in agile software development. What is Planning Poker and how is it used in software development?

 

Note for website visitors - Two questions are asked every week on this platform. One on Tuesday and the other on Friday.

• All questions so far can be seen here - https://www.benchmarksixsigma.com/forum/lean-six-sigma-business-excellence-questions/
• Please visit the forum home page at https://www.benchmarksixsigma.com/forum/ to respond to the latest question open till the next Tuesday/ Friday evening 5 PM as per Indian Standard Time. Questions launched on Tuesdays are open till Friday and questions launched on Friday are open till Tuesday. 
• The best answer is always shown at the top among responses and the author finds honorable mention in our Business Excellence dictionary at https://www.benchmarksixsigma.com/forum/business-excellence-dictionary-glossary/ along with the related term

What is Planning Poker?

Planning poker is a prevalent estimation technique typically used in Agile based software development companies. It is an easy, fun and consensus based method used to estimate complex feature development efforts with better precision and predictability. The term “Planning Poker” was coined by James Grenning and promoted heavily by Mike Cohn.

A typical Planning Poker is a set of cards, just like playing cards, but now we have numerous plugins, apps and software programs available as an alternate, especially useful for geo-distributed teams.

 

Background

An estimation has an essential place in the software development world as any scaled development, especially within remote teams, can make the cost, resources and feature availability difficult for business. With a proven and widely accepted estimation practice like Planning Poker, earlier mentioned challenges become much more transparent with potential visibility on cost, resource usage and time to market. Via Planning Poker, teams can estimate a feature development effort without getting influenced by other participants, thus making effort estimates reasonable, predictable and pretty much a standard practice.

Planning Poker is based on the Fibonacci series to assign a point cost to a feature or user story. The Fibonacci series is a series of numbers generated by adding the two preceding numbers collectively to get the next number in the series: 0, 1, 1, 2, 3, 5, 8, 13, 21, and so on. An example illustration of Planning Poker cards may be referred in the image below.

 

(Image credit: Wikipedia)

 

For Agile estimation reasoning, few of the numbers were changed, resulting in the sequence like 1, 2, 3, 5, 8, 13, 20, 40, 100. There are some special category cards included as well like ½, ∞, ? and ☕ for example. The values constitute the range of story points, ideal days, or any other unit the team prefers. There are several cards of a single unit in a Planning Poker deck and it is possible to use multiple decks given the number of participants.

One of the significant reasons to use planning poker is to avoid the influence of the other participants. It enables individual thought process on reasoning and complexities hence as a best practice; all the participants show their cards at the same time after a round of feature related discussion.

 

How does it work?

1. Firstly, the cards are distributed among development team members, ensuring that everyone has a minimum of one card from the Fibonacci series and special category cards.
2. The “Product Owner” role reads out an Agile user story or feature description to the development team. An example user story for a sample development sprint may be:
   • A customer walks into a coffee shop and presses the token machine button.
   • A token number is generated in sequential order, printed on a paper, dispensed for the customer and updated in the reservation queue.
3. Development team members make estimates of the number of story points by simultaneously presenting the cards to everyone.
4. After the reflection period (typically 1 or 2 minutes), excessive and occasional estimates are explained.
5. The goal here is to retain only one value of story points hence in tandem with reasoning and analysis; the process is repeated till all the estimates converge. 
6. Afterwards, respective estimates are updated in the tracking software for a specific work item under Story Point field (or any other preferred unit field) for resource and sprint planning purpose.

It is essential to know that for any uncertainty or incomplete requirement, the infinite (∞) or question mark (?) cards are selected respectively. 

 

Best Practices

• A minimum of 5 people is recommended for a good Planning Poker estimation session.
• The level of knowledge shouldn’t be uneven; for example, an SME and a trainee employee shouldn’t estimate individually. A pairing approach comes handy in this sort of situation.
• Moderation of the Planning Poker session is always recommended to ensure everyone can express themselves, avoid soft consensus and facilitate time monitoring.

 

Planning Poker:

Planning poker which is also called as ‘scrum poker’ was first coined by James Grenning and later popularized by Mike Cohn in his book “Agile Estimation and planning”.

 

Planning Poker is a fun way and secured method used mostly in estimating effort, relative size of the team or duration, size of the goals in software development. It is a gamified technique to guide the team on planning and to have an consensus based, accurate and unbiased estimate.

 

Planning poker is a variant of wideband Delphi Technique. Planning poker combines three estimation technique which are 1. Wideband Delphi Technique 2. Analogous estimating Technique and 3. Estimation using WBS (Work Breakdown Structure).

Planning poker avoids the influence of participants. If a number is called out, it may sound suggesting, recommending, or influencing other participants. It provides space to thin k people independently.

 

 

Wideband Delphi Technique:

Wideband Delphi Technique involves greater interaction and more communication among the experts who are participating. Coordinator calls a group of experts to discuss the estimation issues and coordinator presents each expert with an estimation form and experts fill out the estimation anonymously. Then coordinator prepares and distributes a summary of the estimates and the experts are again called for the meeting focusing on discussing the points which are varied widely. This iteration of meeting continues until it arrives an appropriate estimation.

 

Analogous Estimating Technique:

Analogous estimation is the technique which use the experience of the similar former projects to estimate the effort or time or cost involved to it. For analogous estimation, more the data available will better the estimate.

 

Estimation Using WBS:

The entire work to be carried out in a project will be identified and well defined which is call as Work Breakdown Structure. Hence by reviewing the WBS with project stakeholders, you will be less likely to leave any work since we had spent time on defining the WBS. Estimation using WBS will be more accurate and precise.          

 

 

Procedure to play Planning Poker:

1.    A Moderator will chair the planning poker.

2.    The Product Owner provides an overview on the user story (Requirements from the client in software development)

3.    Team will be provided to ask questions to clarify on assumptions and risks.

4.    During discussion, members should not mention numbers.

5.    Summary might be recorded by moderator.

6.    Everyone who are playing will choose a card and keep it face down. The number in the card will represent the unit of his/her estimation.

7.    Everyone turns the card simultaneously.

8.    People with high and low estimates are allowed to justify their estimation, proceeding with that discussion will continued to the team.

9.    Repeat the estimation process by choosing cards until the consensus is achieved.

10. In software development, developer might like to hold high value of estimates and project manager wants it to be minimum. However,moderators will contribute to arrive to a consensus.

11. To ensure the discussion in structured manner, Moderator or product owner can handle timeclock. After timeout, another round of poker will be played.

 

Benefits of Planning Poker:

 

Expert opinion: Expert opinion provides an estimate relying on his own experience, intuition, or gut feel. Expert opinion doesn’t take much time comparing to some other analytical methods.

 

Analogy: Analogy provides accurate results as the user story in the given case is compared with similar user stories which are implemented. It provides experience as base for the estimation.

 

Dis-aggregation: Dis-aggregation is done by splitting a user story in to smaller and easy to understand user stories. Then the estimation will be done for each and every individual smaller stories. It is also providing a base for analogy as smaller stories are comparable with many of the similar stories in the past.

Planning Poker is agile estimating & planning techniq which is consensus based. just To start  poker planning session. the Product owner or Customer reads an agile user story or describes  feature to the estimators. 

Each Estimator is holding a deck of Planning Poker cards with values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and so forth, which is the sequence we recommend... The values represent the number of story points, ideally, or other units in which the team estimates...

the estimators discuss the features & asking question of product owner As needed. @When the feature has been discussed, each estimator privately selects 1 card to represent his estimate. All cards are then revealed later at  same time.

If all estimators selected the same value@ that becomes the estimate. If not, the estimators discuss estimates.@ the high & low estimators  specialy share their reasons. After further discussion, Each estimator @reselects an estimate card, and All@ cards are again revealed at the same time.

poker planning is repeated until consensus is achieved or until the estimators decide that agile estimation and planning of particular item needs to be deferred until additional info can be acquire.

 

This is used in Software development while making decision 

to ensure every one is agree on the decision part 

 

Some the steps used in the Planning Poker process. It assumes that the estimation process is occurring with everyone present in the same location, but with minor changes the process can be performed in a distributed manner.

A moderator chairs the meeting to ensure that each member adheres to the guidelines
A product manager or similar team leader provides an overview of the feature set or user story that is to be estimated.  The team can ask clarifying questions about assumptions and risks.  there should be no mention of number tht might indicate the specific amount of effort  feature will take in order to avoid anchoring.  A summary of the discussion is recorded.
Each person involved in the estimation process will determine how much effort is required and lay a card face down in front of them reflecting that estimate. Then everyone turns their cards over simultaneously.
Those who have significantly higher or lower estimates are given the chance to justify the estimate.
The process repeats until all estimates converge around the same value.  A timer can be used to ensure that each round of estimation doesn’t take too long.

Q 265. Planning Poker is a gamified technique for estimating, more commonly used in agile software development. What is Planning Poker and how is it used in software development?

 

What is Planning Poker?

Planning Poker is also called Scrum Poker, an agile estimating or relative size of development goals and planning technique in agile software development that is consensus based. To start a poker planning session in agile software development, the product owner or customer reads an agile user story or describes a feature to the estimators. 

 

In planning poker, the respective members of the group individually make estimates by playing numbered cards face-down to the table, instead of speaking them audibly. The cards are revealed by Moderator/Agile Coach, and the estimates are then discussed. The main objective of hiding the figures in this way, the group can avoid the cognitive bias of anchoring, where the first number spoken audibly sets a precedent for subsequent estimates.

 

Planning poker is a difference of the Wideband Delphi method, it is mostly commonly used in agile software development cycle, in particular in Scrum and Extreme Programming.

 

Planning Poker Process in Agile Software Development:

i)                   Rationale:

The reason to use planning poker is to avoid the influence in particular of the other participants. If particular number is spoken, it can sound like a suggestion and influence the other participants' sizing. Planning poker should force people to think independently and propose their numbers concurrently. This is skillful by requiring that all participants might show their card at the same time.

 

ii)                 Equipment:

Each estimator in agile team is holding a deck of Planning Poker cards with values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100, which is the sequence we recommend. The ethics represent the number of story points, ideal days, or other units in which the team estimates.

The estimators discuss the feature of particular product and asking questions of the product owner as needed. Once the feature has been fully discussed with in the team, each estimator confidentially selects one card to represent his or her estimation. All the selected cards with in the team are then revealed at the same time.

 

If all estimators nominated the same value, that becomes the final estimation for agile development. If not, then the estimators need to revisit their strategies and discuss their estimates again. The high and low estimators should share their reasons. With follow-up further discussion, each estimator reelect an estimate card, and all cards are again revealed at the same time.

 

Poker planning process shall be repeated until consensus is achieved.

 

iii)              Procedure:

At the time of estimation meeting, each estimator is given one deck of the cards. All the decks have identical sets of cards with in them.

 

  

 The Agile meeting proceeds as follows:

i)                   Agile Coach or a Moderator, who will not play, generally chairs the meeting.

ii)                 The Product Owner or Business Analyst plays a key role, provides a short overview of one user stories to be estimated. Each team is given an opportunity to ask question freely and discuss accordingly to get more clarity on assumptions and risks. The summary of the discussion is recorded by Moderator.

iii)               Each individual lays a card face down representing their estimate for the story. During Agile estimation revealed discussion, numbers must not be mentioned at all in relation to feature size to avoid anchoring.

iv)               Everyone calls their cards simultaneously by turning them over.

v)                  People with high estimates and low estimates are given a soap box to offer their justification for their estimate and then discussion continues.

Soapbox: A soapbox is a high platform which one stands on to make impromptu speech independently, often about a political subject.

vi)               Repeat the estimation process until a consensus is reached.

vii)             To ensure that discussion is organized and well structured; the Chairperson/Moderator or the Product Owner may at any point turn over the egg timer and when it runs out all discussion must conclude and another round of poker is played. The construction in the conversation is re-introduced by the soap boxes.

 

Agile Perspective due to the Impact of COVID-19 Global Outbreak:

Due to the impact of COVID-19 global outbreak, Many Organizations over the globe is making powerful changes to adjust to the new virtual reality, digital transformation in fourth industry revolution (Industry 4.0/Service 4.0), moving all the possible functions online including Training, Team meeting and Stakeholders making decisions with social distance, HR, Marketing, Sales, Finance and Cyber Security and HSE systems, and naturally, IT.

 

Agile business analysis ensures that information is available to the agile team at

the accurate level of detail at the exact time. The strong agile team should be formed with Lean mindset and scaled agile business planning as well. Agile Business analysts help agile teams to answer the following important questions:

 

i)                 What need are we trying to satisfy?

ii)                Is that need worth satisfying?

iii)               Should we deliver something to satisfy that need?

iv)               What is the right thing to do to deliver that need?

 

Business Analysis Core Concept Model in Agile Software Development Cycle:

Agile team might consider BACCM (Business Analysis Core Concept Model) while estimating Agile software development cycle or incremental approach under any critical situations.

1.     Value

2.     Solution

3.     Need

4.     Stakeholders

5.     Context

6.     Change.

Definition: We as an Agile Team to deliver a Value from a Solution to a Need of Stakeholders within Context of Change.

 

Organizations new to the agile mindset and practices, a primary focus on continuous improvement, ongoing changing behavior, faster and high-quality delivery and making growth enables the organization to move towards culturally adopting the agile mindset. Adopting the agile attitude refers to the cultural adoption of agile principles as opposed to the organization considering agile as a methodology or practice to be implemented.

 

During agile initiatives, scope is constantly evolving which we cannot avoid. This is managed by the product backlog list by respective product owners which is continually reviewed and re-prioritized. This process contributes to the refinement and redefinition of scope in order to meet the evolving and emerging business need.

 

If a major change emerges that significantly impacts the overall value and goals

for the project, the respective agile project can be adjourned and reassessed based on following.

 

i)                 Breadth of Change

ii)                Depth of Change

iii)               Value and Solutions Offered

iv)               Delivery Approach.

v)                Major Assumptions.

 

Before deciding Agile implementation in any Organization, an agile sponsor understands and accepts the following:

 

i)                  Use of adaptive planning (Change driven) over predictive planning (Plan driven),

ii)                 Use and value of a fixed period of time for a work cycle (Agile software development or Incremental), and

iii)               Need and value of the sponsor’s engagement, participation and collaboration.

 

Benefits:

Planning Poker leads to better estimate is because of business analysis brings people together and ensures that multiple expert opinions with the agile development or incremental approach team at right time. Because these experts form a cross-functional team from all disciplines on a software development project, they are better suited to the estimation task and simplification.

Planning Poker business technique provides the following major benefits in Agile Software Development:

i)                Accurate Estimates on Time

ii)               Equal Voice/Equal Contribution (Agile Team)

iii)              Facilitating Team Coordination

iv)              Facilitates Implementation Strategy

v)               Empowered Agile Team and Self-Organizing.

vi)              Focus on Business Value (Stakeholders)

vii)             Faster and high-quality delivery (Lean)

viii)            Continuous Improvement

 

References:

https://en.wikipedia.org/wiki/Planning_poker

https://www.mountaingoatsoftware.com/agile/planning-poker

https://www.iiba.org/

 

Thanks and Regards,

Senthilkumar Ganesan.

Email: [email protected]

Mobile: +91-7598124052.

What is Planning Poker??

Planning poker also known as Scrum poker. It is a team building activity where all team members involved for achieving group consensus, based on this consensus team come to know how long a certain amount of work will take to complete. planning poker is often associated with Agile software development, this activity can be used with any group that needs to estimate the time it will take to complete a project. 

In this activity each person of development team actively participates in the estimation process and contributes his/ her knowledge.  It is especially useful for projects in which there can be a lot of unknown variables and multiple areas of expertise are required in order to get an accurate estimate. Planning poker was first described  by James Grenning in 2002, it is a more informal version the Wideband Delphi Method, an approach to achieving consensus developed by the RAND Corporation in the 1940s.

 

Following are Key Steps in  Planning Poker, which help to develop estimation for Project.

 

1.Product owner/Customer reads story: This is first step of Planning pocker where to start session, the product owner/customer reads an agile user story or describes a feature to  all team members.

2.Team estimates: After listening story from Product owner, Team members of the group make estimates by playing numbered cards without revealing their estimate. Following are Interpretation of the point assigned to a poker card

 

 

3.Team discuss: After step 2, cards are displayed one by one  and the estimates are then discussed , however some cards will be different from others.  At this point, the facilitator moderate a discussion and invite the team members who threw high and low cards to explain their rationale.  The business owner’s role at this time is to answer questions.

 

4.Team estimates again: The process is repeated until the group achieves consensus or the facilitator decides that consensus cannot be reached and the story must be broken down into simpler parts before the project can move forward.

 

Benefits :

•In this activity discussion among team member leads towards accurate estimation.

•It offers an opportunity to leverage the knowledge of all team members.

•Each Team members get opportunity to justify their estimations.

•Time estimates are based on group consensus rather than an individual's opinions, thus increasing buy-in by the entire team

•It fosters a deep discussion of the reasons for various time estimates, which leads to better knowledge among the participants.

 

Limitations :

•Estimation changes with the different skills and experiences.

•Meeting may take longer time if moderator not managed well.

•The results from planning poker exercises can also be a little too hot to handle.

Planning poker  is a consensus-based, gamified technique used often for estimating the effort required to accomplish a certain goal or relative size of development goals in software development. In planning poker, members of the group make estimates by playing numbered cards face-down to the table, instead of speaking them aloud. When all have played their cards, the cards are revealed simultaneously, and the estimates are then discussed. By revealing the figures at the same time, the group can avoid the cognitive bias of anchoring, where the first number spoken aloud influences the estimate other participants will make. The design of this process was to help software organizations more accurately estimate development timeframes, build consensus among the members of the cross-functional team, and more strategically plan the team’s work.

The steps involved in planning poker are explained below;

 

Step 1: Hand out the cards

Participants are all given an identical deck of cards, each with a different number. The most common sequence used is the Fibonacci sequence, each number in the sequence is the sum of the 2 preceding number in the sequence.The decks are limited and well staggered, because the goal is for all participants to reach a consensus number for each story. This is to increase the efficiency of the process.

 

Step 2: Read the story

The product owner will read each story out loud to everyone in the group.

 

Step 3: Discuss

Since everyone is now aware of the story, it is time to discuss about it. This also a time to ask questions so that confusion will be eliminated. Participants will describe the ideas they have about how the work will flow, how many people they estimated will be required to get the job done, which skill sets will be required, and what if any obstacles they envision slowing progress.

 

Step 4: Estimate and share

When all discussions and questions have been concluded, each person will secretly choose a card from the deck to represent their estimate of story points. They will then reveal the numbers on their cards simultaneously.

 

Step 5: Work toward consensus

If all participants’ reveal the same card, then that number becomes the consensus. The group can move on to the next story. If the numbers are different, there will be another discussion where people at the extremes will explain their choices, more insights will be shared among the team members. Another round is then conducted where participants will make new choices. This process will be reiterated until consensus is built among the participants.

Scrum is a framework that helps teams work together and address the complex adaptive problems among themselves for highest productivity and delivering products. Out of many Agile processes, Scrum is a process to focus on delivering the business value in the shortest period of time. It’s main philosophy is “fail fast”, so that you can learn from your failures. Scrum was created by Ken Schwaber and Jeff Sutherland and they wrote its values are Courage, Focus, Commitment, Respect, and Openness. The Scrum Team consists of a Product Owner, the Development Team and a Scrum Master and the Scrum Teams are self-organizing and cross-functional. 

 

Planning Poker is an agile estimating and planning technique that is based on consent of all the members and it is also known as Scrum Poker. The main objective to play the game is that every single person should come to the same point of consensus. Planning poker session usually starts after an initial product backlog is written.The Scrum Master acts as the moderator or facilitator of the meeting and the Product Owner may be present as an observer. Planning Poker generally uses the Fibonacci Number to assign a point value to a feature or user story. Planning poker can be a useful estimation technique for any team in any organization, but the approach fits basically well for smaller jobs and smaller teams.

 

 

The steps of planning poker game are given below:

 

1. Each estimator or stakeholder will have a deck of Planning Poker cards with values like 0, ½, 1, 2, 3, 5, 8, 13, 20, 40 and 100. The values of the poker card represent the number of story points or other units in which the team estimates.Higher the value of the card means high significance for that particular user story or other units.

2. The members of the group then place the number cards face down on the table rather than utter them loud.

3. Starting a poker planning session, the product owner reads or describes a user story to the estimators or stakeholders.

4. The stakeholders or estimators will then have a discussion on the point and will ask the product owner to clarify any respective query. Then all members of the group will select privately one card to represent their estimate and all cards are then revealed at the same time.

5. If all the people will select the same number then it will become the estimate. 

6. If there is a variance between the card numbers then they will further discuss the respective points. The main concern of discussion will be the lowest and highest values given the estimator or stakeholder.

7. After the discussion, again they will select the cards and again all the cards are revealed at the same time.

8. The poker planning game is repeated until concord is achieved or until the estimators or stakeholders decide that estimating and planning of that particular item needs to be postponed until further information is obtained.

 

The Interpretation of the point assigned to a poker card is listed in the table below:

Card Value	Interpretation
0	Task completed
1/2	Task is very small
1,2,3	These values are generally used for small sized tasks
5,8,13	These values are generally used for medium sized tasks
20,40	These values are generally used for large sized tasks
100	The value is generally used for very large sized tasks
?	No idea how much time it will take to complete the task
infinity	The value is generally used for very very large sized tasks
Cup of Coffee	I need a break

An effective estimation is the toughest challenge that a software developer faces in their jobs. Whatever may be the size of the team, they need to define, estimate, and distribute work throughout a project team. Hereby, planning poker (also known as Scrum poker) is a consensus-based, gamified technique for estimating, mostly used to estimate or  develop goals in software development.

Poker Planning is a consensus based popular agile estimating technique.It is used for estimating agile development work. This is highly used while sizing(estimating) the Product Backlog items(PBI-say requirements often conceived as user stories)   

 

How does it work:
A set of planning poker cards are used for estimation. Each card has a value printed on the card. The values(numbers) displayed on the cards usually is made up of Fibonnaci series...0,1,2,3,5,8,13,20,40,100 (up until the value of '13') and beyond that it will be specifically have a value of '20', '40' and '100'. The values indicate the size of the story. Size of the story will be determined by Effort, complexity,Uncertainity. So beyond the value of '13', most organisations do not try to size a story. Beyond '13', it is too big to complete a PBI within an iteration/sprint. Therefore, rather than using a fibonnaci series as a value, the values -'20','40','100' are used.

 

Poker Planning can be used for PBIs sizing (Where it may involve the entire scrum team) and also for sizing PBIs in sizing PBIs in a given sprint/iteration (where PBIs are refined and where Dev Team would be predominantly involved in estimation unless there are some outstanding queries which require Product Owner' help)  
 
Let us take an example of how this poker planning works in a Sprint/Iteration planning.

During Sprint/Iteration planning, after first part of the planning is done(when the scrum/agile team picks the right amount of work), in the second part of planning, the team does the estimation on each PBI. Everyone in the development team does the estimation using Poker Planning. The Dev team discusses the PBI and once done, estimation process starts and 1 minute is normally used (or when all concur to show their cards). Every developer will choose one of the cards based on his/her understanding of the complexity of the PBI.

 

The developer retains his/her privacy of the card(as what he chose). Once the time is up, all flip their cards and show their chosen values. If all of the developers choose same value, then that value becomes estimate for the chosen PBI. If there are discrepancy in values, it is being discussed and if required, another round of poker planning is done. In a team of 5, if 3 developers agree for a common value (say '8') and 2 developers have a low (say '3')and high value (say '13') respectively then there will be a discussion on the basis for such extremmes so that proper consensus reached. For all PBIs , this exercise is repeated until there is no item left 

Advantage of Poker Planning:
1. It takes a consensus from the entire team (Dev/Scrum team)
2. It is a better scientific approach and involves data on complexity, effort and uncertainty   
3. Estimation techniques like analogous estimation , expert judgement require past projects experience or expertise. This is about the using of collective wisdom
4. Because it is input obtained from various cross-skiled persons, it eliminates bias and there is more accuracy

 

Conclusion:
Poker Planning serves as a great estimation technique. Because of the advantage that it has, it is used widely in the software industry

Planning poker is a collaborative estimation technique used by Scrum teams to determine the story point values for each story in a sprint by gathering estimates and adjusting them after listening to the reasoning behind the low and high values team members have given.

 

In planning poker, the team explains their estimates while they decide the number of story points for each story, and then they end up coming to an agreement on both the approach and the estimate

 

Once the team has a prioritised list of user stories to get started with, they need to figure out how much effort it will take to build them. The team estimate the story points required to build each story out as part of the Scrum planning meeting at the start of each sprint. Most often the team knows which stories are the highest priority by looking at the backlog, so they try to commit to as many high priority stories as they can in each sprint. One way the team does this is planning poker.

 

How  planning poker used in software development :

 

 

1.     The setup

 

Each team member has a deck of cards with valid estimation numbers on each card. Usually the

Scrum Master moderates the session. When the team can’t be in the same room to use cards, the team will agree on the point scale they’re going to use up front and a method for communicating estimates. Many distributed teams will have everyone provide their estimates over an instant message system to the moderator instead of using physical cards.

 

 

2.     Understanding each story

 

The team goes through each story in the sprint backlog in priority order with the Product Owner and asks questions about the story to figure out what the users need.

 

3.     Assigning a story point value

 

Post the discussion of the feature, each team member need to assigns a story point value by choosing a card from the deck and shares that value with the group.

 

4.     Explaining the high and low numbers

 

              The estimates may differ between team members they assign the low number and the high number to explain their estimates.

 

                  For example: 1 – 2 – 3 – 5 – 8 – 13- 21

 

2 is the low estimate. Maybe the person who estimated it knows a way to develop the feature faster than the rest of the team is assuming.

 

The person who estimated 8 points might know of some complexity to the feature that the rest of the team isn’t thinking of.

 

3 people thought the feature was 3 points

 

5.     Adjusting the estimates

 

Once the team has heard the explanations, they have a chance to choose an estimation card again. If the team can’t be in the same room, they communicate their estimate using e-mail or IM to the moderator without sharing it out loud to the team.

  

6.     Converging on an estimate

 

In general teams begin with a significant range of estimates but that range narrows over the course of explanation and adjustment. After a few iterations through the process, the estimates converge on a number that the team is comfortable with. It  takes 2-3 iterations of discussion until the team can unanimously agree on a story point value.

 

Planning poker is very useful technique and is effective, in part because it’s collaborative. When the team estimates effort for the story point, each team member estimates the whole effort, not just his or her part of it. So even if you’re not doing the work, you’re estimating it... and that helps everyone on the team get a better understanding of the whole project.

Q 265. Planning Poker is a gamified technique for estimating, more commonly used in agile software development. What is Planning Poker and how is it used in software development?

Planning Poker

Planning Poker is a consensus-based approach to estimate relative size of goals or deliverables in an agile software development. It is also called as scrum poker. This technique was first derived and named by James Grenning, later familiarized by Mike Cohn in his book Agile Estimating and Planning. It is a variation of the ‘wideband delphi’ method, developed by RAND Corporation.

In this method, project team members play the numbered cards repeated times to converge at an estimate. Hence, it avoids the problem at the opposite ends of the spectrum. On one hand, it saves the team’s valuable time by eradicating long term discussions or meeting. On the other hand, since the team is playing the cards simultaneously, the method prevents anchoring (or) cognitive bias arising in a sequential method.

 

Execution model in software development

1.     In this technique, the entire scrum team (Product Manager, Scrum Master, Business Analysts etc.) is involved in the process. The number of rounds may vary for each user story depending on its estimation difficulty level.

 

2.   Planning poker is played with a deck of cards and those cards have numbers are arranged usually in Fibonacci series (1, 2, 3, 5, 8, 13, 21, 34,). The numbers indicates the estimation value or story points for each use case.

 

3.     Product owner or any one of the team mate is selected as a moderator who reads the user stories one by one for which the estimation is being calculated. Any final decision was authorized by him also in case of estimators have any questions he clarifies it.

 

4.     When the moderator explains the first user story, estimators have to select a card privately which represents story points given by the estimator to the particular user story. After all the estimators have made their decision, all the cards are simultaneously turned over and held face up so the estimators can able to see others points.

 

5.     By the end of first round all the points are very likely to be varied. The high and low estimators explain the reason for their estimations and if there is any contradictions others can involve in the discussions. Importantly moderator has to ensure the discussions are going in smoother way. He can note down the important points will be helpful in the development phase.

 

6.     After the discussion, each estimator again re-estimates by selecting a card privately. When estimators finished the estimation once again all the estimators turn over their cards at the same time.

 

7.     Repeat the process until all the estimators converged to a single estimated story point/range for the particular user story.

 

 

 

 

Effectiveness of planning poker in software development:

1.     Team can easily know about the different perspectives or difficulties in current user story. It leads to perfect estimation of task completion time. For example testing team may not know about the pain of development team and vice versa. Testing team have to build a new framework for the current user story but programmer part was easy in this case.

 

2.     Some user stories are hard to estimate in this case team will split it into fragments and they can easily do estimation for this fragmented user stories. 

 

3.     Code quality can be improved by planning poker estimation because in normal process it does not involves any sort of detailed discussion so it may cause code change or code deletion. Here it is avoided completely and improves code quality.

 

Problems

1     Product Uncertainty

2     Technical Uncertainty

3     Time consumption

Solutions

• Team has to hold the story until its uncertainties are resolved.
• Use range as the estimate. So team mates has limitations while choosing points. For example range may be of 1 to 100.
• This techniques uses bubble sort so it consume more time in fixing accurate points to user story. So it can be avoided by any one of the team member picks a number and goes on by convincing others.
• Also time consumption was improved by establishing two values as a baseline. This can be done before starting the game by simple discussions. It is easy to choose between two numbers (e.g: 3 and 8 as baseline) than between range.

Planning poker is an Agile Estimating technique.Estimate is the evaluation of the effort that is required to complete the development of any task or project, this is mostly measured in terms of time take and the objective of breaking up into smaller timelines is to aggregate many individual estimates to arrive at the overall timelines or duration for the project and also the effort required and the estimated cost that would be required to carry out the project.

Planning Poker  - This is a technique which is based on the consensus of entire team who are part of the project. This is used to estimate the project backlog in agile estimation and planning. 

How is planning poker used ?

Before starting the project each person who are part of the project team will be hold a deck of planning poker cards, each card would be assigned with a number (0,1,2,3,5,8,13,20,40 and 100), the user or customer would then describes the feature or agile story on requirements to the project team/estimators The team would brainstorm and understand the requirements clearly and understand all the aspects of requirement and its complexity .Once they have an understanding ,each member of the team  selects a card to provide the individual estimates.Once the whole team picks up the card all values that the team members selected are collectively displayed and that becomes the estimate from each of the team members.If the estimates provided by all the team members are the same, that is finalized as the final estimate however in case there is a variance in the estimates that are provided by the different team members there is another round of discussion to explain the rationale behind choosing the same differently. Mostly in case we have people who have selected the extreme values the highest and least estimator will have to provide the reasons for the same and once this is done the cards are re selected and revealed at the same time. The process is repeated until all of them are calibrated and reach consensus around the same estimate and that is when the process is completed.In case the numbers are consecutive the larger one is picked up as estimate, this would avoid  underestimating the effort and struggle to meet timelines. in case we have only one project team member showing extreme value, we need to understand the root cause if it is on account of technical issue or understanding of product feature.In this case through research should be done in understanding the same...this is more a collaborative approach where the entire team reaches consensus on delivering any project.

Other techniques for estimation are Story points , ideal dates etc.

Benchmark Six Sigma Expert View by Venugopal R

Team based activities require different kinds of motivation. Those who have played the roles of facilitators for engaging cross functional employees on team exercises need to keep evolving interesting ways on an on-going basis, to get the best from team sessions.

 

Many of us would be familiar with some of the voting techniques like Delphi method that are used as part of the Improve phase in a DMAIC cycle and for many other situations. Planning Poker is a similar method used popularly as part of Agile Scrum framework, by which the size of a user story is determined with consensus. A user story, in software development refers to description of a software feature from an end-user perspective, in natural language. Sizing of a user story is done considering the quantum of work involved, the complexity of work, risks / uncertainties, time duration etcetera.

 

The team members, during a facilitated meeting, are given the overview of the story and asked to estimate the size of the project by independently selecting a card from a set of cards.

 

The set provided to each participant will contain cards bearing different numbers, usually as per Fibonacci series. Each team member independently selects his / her number that represents the size of the project according to his / her assessment.

 

The team member should not disclose his / her choice to others until everyone completes the voting and the cards are flipped by everyone, when asked to do so, at the same time.

 

Evidently the purpose of doing the secret voting is to avoid the possibility of anyone getting influenced by another’s voting and to obtain independent views.

 

The term “Planning poker” was first introduced by James Grenning in 2002 and term became more popular through the book on ‘Agile Estimating & Planning’ by Mike Cohn.

 

Fibonacci series (1,2,3,5,8,13….) is used to allow a significant difference between the voting choices. Apart from cards, usage of mobile apps and collaborative software have also emerged, thus enabling team member from remote locations to participate.

 

The below steps depict the typical procedure for Planning Poker:

1. Team members meet physically or remotely
2. The meeting is moderated by a facilitator who will not vote
3. The user story to be estimated is presented, usually by the product owner
4. Any questions / clarifications are addressed by the presenter
5. Each individual chooses a card representing his / her estimate and the card is placed face down. Individual choices are strictly not to be disclosed at this point. It may be noted that if there are remote participants, other voting tools are used.
6. When required by the facilitator, all team members flip their cards at the same time
7. In case there is extreme difference in the voted numbers, those team members are asked to justify the reasons for their outlying voting.
8. The estimation process is repeated until a consensus is arrived.

 

Certain points of caution to be exercised while using Planning Poker:

1. Like any other project management tool, this technique works based on how well it is implemented. The tool cannot replace the creativity and the presence of mind required by the Scrum master.
2. Scrum masters at times would be under pressure to arrive at the story points and may start declaring the points even before they complete the exercise
3. The ability to gather the right set of team members and holding their attention through the exercise is often a challenge
4. Any disclosure of the points before it is called for, defeats the purpose of the exercise.
5. People tend to mis-interpret and compare the story sizes based on the value of points, whereas the effort levels need not be proportional to the values that are based on Fibonacci series.
6. Too many stories should not be attempted for being sized in one session
7. If the list of acceptance criteria is too long, it could be an indication that the story is too long to fit into a sprint.
8. Sometimes the focus is more on the development side and the points for testing effort may get left out or given lower attention

What is Planning Poker?

 

Planning Poker is an agile estimating and planning technique that is consensus based.

The owner or customer announces an agile user story or explains a feature to the estimators in order to start a poker planning session.

 

Participants (or called estimator) are holding Planning Poker cards with values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100. The values symbolize the number of story points, working days, or other units in which the team estimates.

The participants discuss the quality of product and they ask quality of product related questions with the product owner. When the story has been fully discussed, each participants confidentially selects one card to represent his or her estimation. They open all the cards together which have been received from individual participants.

If all participants selected the identical value, that becomes the estimate. If not, the estimators discuss their estimates. The exceptional results must be discussed with their explanations to understand the exceptional difference. Again same process repeated based on discussion, and then open all the cards at same time.

This process repetitive till consensus is succeed or participants agrees that estimation planning could be delayed till more information collected.

 

This works as better estimation methodology as it is organized with cross functional or multiple expert concepts/views.

 

 

 

Planning poker is mostly used to estimate efforts or relative size of development goals in software development.

 

 

How is it used in software development?

 

So as explained above that its great to have multiple expert/Cross functional participants/estimators to start poker planning hence in Software development, different stakeholders can be added a team, a product owner, Software developers, UX designers, QA testers, Operational expert, product managers and a common user of similar product from the same organization. 

 

Story = User Download a Trial version of Game

 

 

Step 1 = Cards

Estimators are given and identical deck of cards with different numbers and keeping in mind with sequence number based on double the numbers 1, 2, 4, 8, 16, 32, 64 with recommended sequence.

 

Step 2 = Read story

Product Manager will read story to the group.

 

Step 3 = Debate

Every estimator has heard the story hence its time to discuss. Each estimator describe how they visualize or understand about playing the game and handling the game software, all the they explained require skill sets, and what if any hurdle comes. they debate and ask questions.

 

Step 4 = Estimate

After debate/discussion, estimator choose a card from deck to represent their estimate of story points.

when everybody is ready, everybody revealed their cards together at same time.

 

The higher a participant’s card is, the more difficult that participant estimates the story will be to complete.

 

Step 5 = Work on Consensus 

 

Condition 1 = If all estimators open the same card, then that number becomes the consensus.

And group can move on to the next story.

 

Condition 2 = If the cards differ, then the group continues its discussion about the story. Those with higher (or lower) estimates than the rest of the group will explain their reasoning and try to convince their group member to see their view.

 

Once the group concludes new round of discussion, everyone will again review their cards and either keep their previous choice or select a new one. All participants will again reveal their cards at the same time.

 

 

Thanks to Source: -

https://www.mountaingoatsoftware.com/agile/planning-poker

https://www.productplan.com/glossary/planning-poker/

https://www.visual-paradigm.com/scrum/what-is-agile-planning-poker/

All answers rightly highlight how Planning Poker is used in an agile software development.

 

The best answer to this question has been provided by Tushar Maradwar, R Rajesh, Satyajit Das and Krutibas Biswal for highlighting the usage and by providing interpretation of the numbers in a planning poker deck.

 

Also review the answer provided by Mr Venugopal R, Benchmark Six Sigma's in-house expert.