Planning poker, also called Scrum poker, is a consensus-based, gamified technique for estimating, mostly used to estimate effort 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. The cards are revealed, and the estimates are then discussed. By hiding the figures in this way, the group can avoid the cognitive bias of anchoring, where the first number spoken aloud sets a precedent for subsequent estimates.
Story points estimation using planning poker which is based on Wideband Delphi method helps to arrive at consensus based estimates using collective intelligence – Wisdom of the Crowds. Story point being a coarse grained or rough estimation technique, it helps in long term planning like release planning. Product Owner need not wait for. Welcome to pointing poker (aka planning poker)!Online, virtual and co-located agile teams use this application during their planning/pointing sessions to effectively communicate points for stories. Planning Poker is an agile estimating and planning technique that is consensus based. To start a poker planning session, the product owner or customer reads an agile user story or describes a feature to the estimators. Each estimator is holding a deck of Planning Poker cards with values like 0, 1, 2.
Planning poker is a variation of the Wideband delphi method. It is most commonly used in agile software development, in particular in Scrum and Extreme Programming.
The method was first defined and named by James Grenning in 2002[1] and later popularized by Mike Cohn in the book Agile Estimating and Planning,[2] whose company trade marked the term [3] and a digital online tool.[4]
- 1Process
Process[edit]
Rationale[edit]
The reason to use planning poker 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. Planning poker 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.
Equipment[edit]
Planning poker is based on a list of features to be delivered, several copies of a deck of cards and optionally, an egg timer that can be used to limit time spent in discussion of each item.
The feature list, often a list of user stories, describes some software that needs to be developed.
The cards in the deck have numbers on them. A typical deck has cards showing the Fibonacci sequence including a zero: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89; other decks use similar progressions with a fixed ratio between each value such as 1, 2, 4, 8, etc.
The reason for using the Fibonacci sequence instead of simply doubling each subsequent value is because estimating a task as exactly double the effort as another task is misleadingly precise. A task which is about twice as much effort as a 5, has to be evaluated as either a bit less than double (8) or a bit more than double (13).
Several commercially available decks use the sequence: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, and optionally a ? (unsure), an infinity symbol (this task cannot be completed) and a coffee cup (I need a break, and I will make the rest of the team tea). The reason for not exactly following the Fibonacci sequence after 13 is because someone once said to Mike Cohn 'You must be very certain to have estimated that task as 21 instead of 20.' Using numbers with only a single digit of precision (except for 13) indicates the uncertainty in the estimation. Some organizations[which?] use standard playing cards of Ace, 2, 3, 5, 8 and king. Where king means: 'this item is too big or too complicated to estimate'. 'Throwing a king' ends discussion of the item for the current sprint.
Smartphones allow developers to use mobile apps instead of physical card decks. When teams are not in the same geographical locations, collaborative software can be used as replacement for physical cards.
Procedure[edit]
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 Moderator, who will not play, chairs the 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. A summary of the discussion is recorded, e.g. by the Moderator.
- Each individual lays a card face down representing their estimate for the story. Units used vary - they can be days duration, ideal days or story points. During discussion, numbers must not be mentioned at all in relation to feature size to avoid anchoring.
- Everyone calls their cards simultaneously by turning them over.
- People with high estimates and low estimates are given a soap box to offer 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 Moderator can negotiate the consensus.
- To ensure that discussion is structured; the Moderator or the Product Owner may at any point turn over the egg timer and when it runs out all discussion must cease and another round of poker is played. The structure in the conversation is re-introduced by the soap boxes.
The cards are numbered as they are to account for the fact that the longer an estimate is, the more uncertainty it contains. Thus, if a developer wants to play a 6 he is forced to reconsider and either work through that some of the perceived uncertainty does not exist and play a 5, or accept a conservative estimate accounting for the uncertainty and play an 8.
Benefits[edit]
A study by Moløkken-Østvold and Haugen[5] reported that planning poker provided accurate estimates of programming task completion time, although estimates by any individual developer who entered a task into the task tracker was just as accurate. Tasks discussed during planning poker rounds took longer to complete than those not discussed and included more code deletions, suggesting that planning poker caused more attention to code quality. Planning poker was considered by the study participants to be effective at facilitating team coordination and discussion of implementation strategies.
See also[edit]
- Comparison of Scrum software, which generally has support for planning poker, either included or as an optional add-on.
References[edit]
- ^'Wingman Software | Planning Poker - The Original Paper'. wingman-sw.com. Retrieved 5 July 2017.
- ^Mike Cohn (November 2005). 'Agile Estimating and Planning'. Mountain Goat Software. Retrieved 1 February 2008.
- ^'Planning poker - Trademark, Service Mark #3473287'. Trademark Status & Document Retrieval (TSDR). 15 January 2008. Retrieved 26 May 2014.
- ^Cohn, Mike. 'Planning Poker Cards: Effective Agile Planning and Estimation'. Mountain Goat Software. Mountain Goat Software. Retrieved 30 March 2016.
- ^K Moløkken-Østvold, NC Haugen (10–13 April 2007). 'Combining Estimates with Planning Poker—An Empirical Study'. 18th Australian Software Engineering Conference. IEEE: 349–58. doi:10.1109/ASWEC.2007.15. ISBN978-0-7695-2778-9. Retrieved 1 February 2008.
- Mike Cohn (2005). Agile Estimating and Planning (1 ed.). Prentice Hall PTR. ISBN978-0-13-147941-8.
What is Planning Poker?
Planning Poker is an agile estimating and planning technique that is consensus based. To start a poker planning session, the product owner or customer reads an agile user story or describes a 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 100, which is the sequence we recommend. The values represent the number of story points, ideal days, or other units in which the team estimates.
The estimators discuss the feature, asking questions of the product owner as needed. When the feature has been fully discussed, each estimator privately selects one card to represent his or her estimate. All cards are then revealed at the same time.
If all estimators selected the same value, that becomes the estimate. If not, the estimators discuss their estimates. The high and low estimators should especially share their reasons. After further discussion, each estimator reselects an estimate card, and all cards are again revealed at the same time.
The poker planning process is repeated until consensus is achieved or until the estimators decide that agile estimating and planning of a particular item needs to be deferred until additional information can be acquired.
When should we engage in Planning Poker?
Most teams will hold a Planning Poker session shortly after an initial product backlog is written. This session (which may be spread over multiple days) is used to create initial estimates useful in scoping or sizing the project.
Because product backlog items (usually in the form of user stories) will continue to be added throughout the project, most teams will find it helpful to conduct subsequent agile estimating and planning sessions once per iteration. Usually this is done a few days before the end of the iteration and immediately following a daily standup, since the whole team is together at that time anyway.
How does poker planning work with a distributed team?
Simple: go to PlanningPoker.com. Mountain Goat Software helped develop that website to offer it as a free resource to the agile community. A product owner, ScrumMaster or agile coach can log in and preload a set of items to be estimated. A private URL can then be shared with estimators who log in and join a conference call or Skype session. Agile estimating and planning then proceeds as it would in person.
Does Planning Poker work?
Absolutely. Teams estimating with Planning Poker consistently report that they arrive at more accurate estimates than with any technique they'd used before.
One reason Planning Poker leads to better estimates is because it brings together multiple expert opinions. Because these experts form a cross-functional team from all disciplines on a software project, they are better suited to the estimation task than anyone else.
After completing a thorough review of the literature on software estimation, Magne Jørgensen, Ph.D., of the Simula Research Lab concluded that “the people most competent in solving the task should estimate it.”
Second, a lively dialogue ensues during poker planning, and estimators are called upon by their peers to justify their estimates. Researchers have found that this improves estimate accuracy, especially on items with a lot of uncertainty as we find on most software projects.
Further, being asked to justify estimates has also been shown to result in estimates that better compensate for missing information. This is important on an agile project because the user stories being estimated are often intentionally vague.
Additionally, studies have shown that averaging individual estimates during agile estimating and planning leads to better results as do group discussions of estimates.
How can I get Planning Poker cards?
Planning Poker Online
Planning Poker cards are available in the Mountain Goat Software store. Mountain Goat Software's branded Planning Poker cards are sold at cost as a courtesy to the agile community.
Our full-color cards are the absolute highest-quality cards available anywhere. They are manufactured by the same company that prints many of the world's most popular playing card brands, including Bicycle, Bee, and the World Poker Tour.
We also offer royalty-free licenses to organizations that wish to produce their own cards. The license is available here: https://www.mountaingoatsoftware.com/agile/planning-poker/license
Recommended Resources Related To Planning Poker
Planning Poker Story Points
- How Can We Get the Best Estimates of Story Size?
- The Best Way to Establish a Baseline When Playing Planning Poker
- Don’t Average During Planning Poker
- Agile Estimating
Courses Related To Planning Poker
Scrum Foundations Video Series
Agile Story Points Planning Poker
All the foundational knowledge of Scrum including: the framework, values, different roles, meetings, backlogs, and improving efficiency & quality.