计划扑克——问答

Planning Poker (also called Scrum Poker) is a consensus-based agile estimation technique used by development teams to estimate the effort or complexity of work items — typically user stories in a product backlog. Participants use numbered cards (commonly following the Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, 21… or T-shirt sizes: XS, S, M, L, XL) to assign relative effort values to each story. All estimates are revealed simultaneously, which prevents anchoring bias and encourages honest independent thinking. When estimates differ significantly, the team discusses the reasons until a consensus is reached.

The most common scale is the modified Fibonacci sequence: 1, 2, 3, 5, 8, 13, 20 (sometimes extended with 40, 100, and special cards like ? or ∞). This scale reflects the natural uncertainty of estimation — the gaps between numbers grow as estimates get larger, which discourages false precision on complex tasks and encourages broader discussion. Other supported scales include sequential (1–10), T-shirt sizes, and hours-based decks.

Story points are the standard unit, typically assigned using a Fibonacci-based scale. However, teams are free to use other scales depending on their workflow: sequential numbers, T-shirt sizes (XS → XXL), hours, or fully custom decks. The key is that the unit is relative — story points measure complexity and effort compared to other stories, not absolute time.

Planning Poker is used during the estimation phase of agile projects to evaluate the effort required to implement features or user stories. It is most common in Scrum but applies to any agile framework. By combining independent thinking with structured discussion, it produces estimates that are more accurate and better understood by the whole team than those generated by a single person or manager.

A typical Planning Poker round follows this order: (1) The Product Owner presents the user story and its acceptance criteria. (2) The team asks clarifying questions. (3) Each team member privately selects a card representing their estimate. (4) All cards are revealed simultaneously. (5) Team members with the highest and lowest estimates explain their reasoning. (6) The team discusses and repeats the round if needed, until consensus is reached.

The primary output is a story point estimate for every user story that was discussed. Each story should have a single agreed-upon estimate that the whole team understands and stands behind. A secondary output is shared understanding — the discussion itself surfaces hidden complexity, uncovers dependencies, and ensures everyone has the same mental model of what each story involves.

The goal is to estimate the effort of each user story and reach a consensus on that estimate. Rather than having a single person dictate how long something will take, Planning Poker distributes knowledge across the team. This creates more realistic plans, surfaces risks early, balances workload, and sets delivery expectations that the team actually owns.

The Scrum Master's role is to facilitate — not estimate. They guide the team through each round, ensure the process is followed correctly, help clarify misunderstandings when needed, keep discussions focused and timeboxed, and make sure every team member has an equal voice. The Scrum Master should not suggest estimates or steer the team toward a particular number, as doing so introduces bias.

Ensuring that every team member actively participates. In practice this means drawing out quieter members, preventing dominant voices from anchoring the group, and maintaining a safe environment where all estimates are valid starting points for discussion. Passive or unbalanced participation leads to lower-quality estimates and reduced team ownership.

Planning Poker is used during sprint or release planning — specifically the backlog estimation phase. The team works through user stories in the product backlog, estimating each one before it is pulled into a sprint. It can also be used in backlog refinement sessions to keep estimates current as stories evolve.

Scope is the most important factor — the breadth and depth of work required, including features, integrations, edge cases, and testing. Beyond scope, good estimators also consider technical complexity (unknown territory, architectural impact), risk (unclear requirements, dependencies on other teams), and effort (the raw amount of work regardless of complexity). The Fibonacci scale is well-suited to these multi-dimensional judgements.

11. The standard Fibonacci-based Planning Poker deck is: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89. The number 11 does not appear in this sequence and is not a standard card value. Teams sometimes add special cards such as ?, ∞ (too large to estimate), or a coffee cup (take a break).

False. All three groups must be present: (1) the Product Owner, who presents stories and answers questions about requirements; (2) the full development team (developers, testers, designers, etc.), whose varied expertise is essential for accurate estimates; and (3) the Scrum Master, who facilitates. Excluding developers from estimation leads to unrealistic plans and removes accountability from the people doing the actual work.

Planning Poker was adapted from the Wideband Delphi method — a structured technique for achieving expert consensus through iterative, anonymous estimation and group discussion. James Grenning described the Planning Poker approach in 2002 and Mike Cohn later popularised it. Planning Poker keeps the core principle of anonymous voting and iterative refinement from Wideband Delphi, while making the process faster and more engaging through the card-game format.

Three common antipatterns to watch for: (1) Influencing estimates — suggesting a specific number or reacting visibly to estimates before all are revealed; this anchors the group and undermines independent thinking. (2) Allowing runaway discussions — letting a single story consume the whole session; discussions should be timeboxed. (3) Unequal participation — letting vocal team members dominate while quieter members stay silent; every estimate deserves an equal hearing.

Planning Poker combines several important properties: it is collaborative (the whole team participates), consensus-based (the team works toward agreement rather than averaging), uses relative estimation (story points, not hours), relies on anonymous voting (estimates are revealed simultaneously to prevent anchoring), is iterative (rounds repeat until consensus), and is facilitated (the Scrum Master keeps the process on track). Together these properties make it more accurate and more engaging than traditional top-down estimation.

No. While Planning Poker was popularised in agile software development, the technique applies to any project where a team needs to estimate relative effort or complexity. It has been used for marketing campaigns, content production, UX research, operations work, and any context where tasks vary in complexity and multiple people's perspectives improve the estimate.