A product team is estimating a saved-payment-method feature for an online checkout. The first vote ranges from 3 to 13. Instead of averaging the cards, the team uses the spread to uncover security, migration, and fallback work.
1. Start with an outcome, not a solution
The backlog item says: “As a returning customer, I want to select a saved payment method so that I can complete checkout faster.” Before opening the voting room, the facilitator asks the product owner to define what success looks like. The team agrees that a signed-in customer can select one previously saved card, see its brand and last four digits, and complete the existing checkout flow without re-entering card details.
That sentence still hides important choices. Can the customer delete a card? What happens when a stored token has expired? Are cards already stored for existing customers? Does the feature cover guest checkout? The facilitator records answers beside the story rather than relying on everyone to remember the conversation.
Agreed boundaries before voting
- Included: list saved cards, select one card, handle an unusable token, and fall back to entering a new card.
- Excluded: adding, renaming, or deleting saved cards; guest checkout; changing the payment provider.
- Done includes: automated tests, accessibility checks, telemetry, code review, and production release.
- Open question: whether older customer records require a data migration.
2. Calibrate the scale with known work
The team uses a Fibonacci-style deck. Before voting, they compare the item with two recently completed examples. A small address-label change was a 2. Adding a new delivery option, including API and UI work, was a 5. The reference items do not convert points into hours; they give “small” and “medium” a shared local meaning.
| Perspective | Vote | Reasoning |
|---|---|---|
| Frontend | 3 | The existing checkout already renders payment options; this looks like one additional selector. |
| Backend | 5 | The payment provider exposes stored tokens, but the API needs a new endpoint and failure mapping. |
| QA | 8 | Expired cards, declined tokens, multiple cards, keyboard navigation, and fallback paths multiply the scenarios. |
| Security | 13 | The story may expose payment tokens too broadly and might require migration of legacy customer records. |
The spread is useful evidence. A vote of 3 describes a UI change built on a trusted API. A vote of 13 describes a security review plus uncertain legacy-data work. Neither person is necessarily “wrong”; they estimated different interpretations of the same sentence.
3. Discuss the edges, not every card
The facilitator asks the lowest and highest voters to explain what they included. The frontend developer assumed that the browser would receive the provider’s complete stored-card response. The security specialist points out that the browser should receive only display-safe fields and an application-owned reference. That requires the backend to map and filter the provider response.
Next, the team checks the migration concern. A developer queries a non-production data sample and confirms that old accounts have provider tokens in the same format. No data migration is needed, but this check becomes a note attached to the story. QA lists the failure paths and the group agrees that an expired token should show a clear message and switch the customer to the existing new-card form.
The backend returns only card brand, last four digits, expiry month/year, and an opaque application reference. Provider tokens never reach the browser. Legacy records need no migration. Delete and manage-card actions remain separate work.
4. Split work only where it creates an independent outcome
The team considers splitting the API from the interface. They reject that split because neither half produces a usable customer outcome on its own. They do separate “manage saved cards” into a future story because customers can use saved cards without receiving delete and rename controls in the same release.
A good split reduces uncertainty or enables independent delivery. A split made only along technical layers can hide coordination work and leave partially finished inventory. If the provider-token investigation had remained unresolved, the team would have created a time-boxed research item and postponed the feature estimate.
5. Revote with the same scale
The second vote is 5, 5, 8, and 8. The remaining difference is about test breadth rather than scope. The team’s agreement says that a one-card gap can be resolved by choosing the higher card when the additional scenarios are required for “done.” They record 8. Another team could revote or use a different convergence rule; consistency and explicit reasoning matter more than the particular rule.
| Before | After |
|---|---|
| Browser might receive provider tokens. | API exposes only display-safe fields and an opaque reference. |
| Legacy migration was unknown. | A data sample confirmed compatible token records. |
| Expired-token behavior was undefined. | The flow displays a message and falls back to new-card entry. |
| Management actions might be included. | Delete and rename controls are explicitly separate. |
6. Record the estimate as a decision with conditions
The useful output is not simply “8 points.” The backlog entry records the agreed boundaries, safe response fields, fallback behavior, and the evidence that ruled out migration. If the provider API behaves differently in the test environment, the team can revisit the estimate because a named assumption changed.
Copyable debrief for your next item
- Outcome: What can a user or operator do when this is complete?
- Included / excluded: Which tempting adjacent work is outside this estimate?
- Reference items: What completed work defines small and medium for this team?
- Vote spread: What did the highest voter include that the lowest voter did not?
- New evidence: Which question was answered during discussion?
- Decision: What estimate, assumptions, and follow-up actions should be recorded?
What this example demonstrates
Planning poker is valuable when voting reveals mismatched mental models early. Averaging 3 and 13 would have produced a plausible-looking number without resolving token exposure, migration, or fallback behavior. The second round is narrower because the team changed the quality of its information—not because anyone was pressured to conform.
Apply the same process with the facilitation checklist, decide how your team resolves close votes with the team agreement template, or create a room for a real session.