Planning Poker

Planning Poker is a group estimation game: each estimator picks a card privately, all cards are turned over together, and the holders of the highest and lowest cards explain before the team estimates again [1], [2]. Its inventor’s purpose: “Precision of individual estimates is not the goal. Determining the project scope is.”

1. Grenning’s game and Cohn’s deck

James Grenning invented it for two problems: estimates took too long, and the whole team was not involved [1]. The customer reads a story; each programmer writes a card without discussing it; all are turned over at once. If they agree, the number is recorded. If not, the programmers at the extremes start the discussion, and with no consensus, “Defer the story, split it, or take the low estimate.” His deck was 1, 2, 3, 5, 7, 10 and ∞, not Fibonacci; the infinity card sends a story longer than two weeks back to be split.

Most teams now use Cohn’s “modified Fibonacci sequence: 1, 2, 3, 5, 8, 13, 20, 40, and 100”, and the rules forbid averaging: “In Planning Poker we don’t take averages or use any number not on the scale/cards.” Consensus usually comes in two or three rounds [2].

Poker belongs to the Delphi family. Classic Delphi is anonymous. Boehm’s Wideband Delphi [3] is not: “the experts meet for group discussions both prior to, and during the estimation iterations” [4]. Poker gives up anonymity altogether for a light, interactive process [5].

2. When to use it, and when not

Use it for release planning of a long backlog, by the team that will build it, on familiar kinds of work. Do not rely on it for stories in unfamiliar territory, where it did worse than plain discussion [6]; for a homogeneous junior team, whose estimates it made more optimistic [7]; or for architecture and infrastructure items unlike the rest of the backlog, which paired comparison can size against a reference.

3. Example

For example, Grenning’s own worked hand: six cards read 1, 3, 2, 3, 5, 3. Only the 1 and the 5 speak. One recalls that changing the communications protocol last time “cost us four days alone!”; the other thinks “all we have to do is add another message class”. The table settles on 3. Most stories took “a minute or so”, against “10, 20, or 30 minutes” before [1].

4. What it fixes, and what it does not

Turning cards over together removes the first speaker’s anchor. Making both extremes explain “introduces compensating anchors” [6]. Two weaknesses remain:

  • The first round fences the answer. The lowest and highest first-round cards bound the consensus: “We found no story having the final planning poker estimate outside these boundaries.” [7] If discussion reveals new work, vote again from scratch.
  • Matching cards hide disagreement. The agreement rule ends the discussion, yet identical numbers can rest on different assumptions. On unfamiliar stories a team “might feel a false sense of security” [6], and initial agreement did not predict accuracy [5].

5. Story points: the advantage and the trade-off

The advantage is Rubin’s observation that “people are much better at relative size estimation than absolute size estimation” [2]. The trade-off: a point means something only inside one team, against one reference, and becomes a date only through velocity — 200 points at 17–20 per sprint is 10–12 sprints. Rewarded, velocity inflates. And relative sizing needs enough comparisons: sizing each story against only two others gave a project total of 99.7 points where a full comparison gave 44.6 [8].

6. Eduardo’s Variation

Eduardo Miranda’s variation adds a baseline and a look at agreement [9]:

  1. With story points, first agree a medium-complexity story as the baseline and give it a 3 or a 5.
  2. Discuss differences and also coincidences, because people may pick the same number for different reasons.
  3. Re-estimate one more time, and record each estimator’s final card.
  4. After all stories, assign the mean and probe the stories with unusual disagreement: “Beware of the blind application of procedures such as averaging.”

Rules 1 and 4 echo his paired-comparison reasoning: a mid-range reference, and reviewing inconsistent judgments [10].

How solid is this?

  • Three studies, each one team or one class. Haugen: median error 0.25 against 0.33 for unstructured discussion, but mean error 0.48 against 0.35 [6]. Moløkken-Østvold and colleagues: slightly less optimistic than the average of private cards, and no more accurate than the team’s usual method, though the team believed it was [5]. Mahnič and Hovelja: worse for students, slightly better for experts [7]. Haugen co-authored the second study.
  • Grenning and Rubin report practice, not data.
  • Eduardo’s Variation is untested and appears in no paper; its source is Miranda’s lecture material.

Acknowledgments

This page adapts material from lectures by Eduardo Miranda and David Root [11] on software project management.

References

  1. J. W. Grenning,
    “Planning Poker or How to Avoid Analysis Paralysis while Release Planning.” Renaissance Software Consulting, Apr. 2002. Accessed: Oct. 11, 2026. [Online]. Available: https://wingman-sw.com/papers/PlanningPoker-v1.1.pdf
  2. K. S. Rubin,
    Essential Scrum: A Practical Guide to the Most Popular Agile Process. in Addison-Wesley Signature Series (Cohn). Addison-Wesley Professional, 2012. [Online]. Available: https://innolution.com/essential-scrum
  3. B. W. Boehm,
    Software Engineering Economics. Prentice-Hall, 1981.
  4. K. Moløkken-Østvold and M. Jørgensen,
    “Group Processes in Software Effort Estimation,” Empirical Software Engineering, vol. 9, no. 4, pp. 315–334, Dec. 2004, doi: 10.1023/B:EMSE.0000039882.39206.5a.
  5. K. Moløkken-Østvold, N. C. Haugen, and H. C. Benestad,
    “Using Planning Poker for Combining Expert Estimates in Software Projects,” Journal of Systems and Software, vol. 81, no. 12, pp. 2106–2117, Dec. 2008, doi: 10.1016/j.jss.2008.03.058.
  6. N. C. Haugen,
    “An Empirical Study of Using Planning Poker for User Story Estimation,” in Proceedings of AGILE 2006 Conference (AGILE’06), IEEE Computer Society, 2006, pp. 23–34. doi: 10.1109/AGILE.2006.16.
  7. V. Mahnič and T. Hovelja,
    “On Using Planning Poker for Estimating User Stories,” Journal of Systems and Software, vol. 85, no. 9, pp. 2086–2095, Sept. 2012, doi: 10.1016/j.jss.2012.04.005.
  8. E. Miranda, P. Bourque, and A. Abran,
    “Sizing User Stories Using Paired Comparisons,” Information and Software Technology, vol. 51, no. 9, pp. 1327–1337, Sept. 2009, doi: 10.1016/j.infsof.2009.04.003.
  9. E. Miranda,
    “Managing Software Development.” 2014.
  10. E. Miranda,
    “Improving subjective estimates using paired comparisons,” IEEE Software, vol. 18, no. 1, pp. 87–91, Jan. 2001, doi: 10.1109/52.903173.
  11. D. Root,
    Managing Software Development. Carnegie Mellon University / Innopolis University lecture series, 2014.

Disclaimer: AI is used for text summarization, polishing and explaining. Authors have verified all facts and claims. In case of an error, feel free to file an issue.

This site uses Just the Docs, a documentation theme for Jekyll.