Planning Poker Examples

Reading the rules only gets you so far - here's what an actual round looks like, start to finish.

Full example: estimating a login feature

User story: "As a user, I want to log in with my email and password so I can access my account." Acceptance criteria: form validation, an error message for wrong credentials, and a "forgot password" link.

Round 1 - private votes:

Dana (frontend)3
Priya (backend)8
Sam (backend)13
Leo (QA)5

The spread is wide - 3 to 13. The facilitator asks Sam (highest) and Dana (lowest) to explain their reasoning first.

Discussion: Sam points out that "log in" implicitly needs password hashing, a rate limiter to prevent brute-force attempts, and a password-reset email flow - none of which are called out in the acceptance criteria, but all of which are part of doing login "properly." Dana was estimating only the visible form and hadn't considered the backend security work. Priya agrees the reset-email flow is the biggest unknown, since it depends on an email service that isn't wired up yet.

Round 2 - after discussion:

Dana (frontend)8
Priya (backend)8
Sam (backend)8
Leo (QA)8

Result: 8 points, unanimous. The discussion did the real work here - once everyone shared what they knew, the number converged on its own. The team also notes that the password-reset email flow might be worth splitting into its own story, since it depends on external infrastructure.

Shorter example: a small bug fix

Story: "Fix typo in the checkout confirmation email." Votes: 1, 1, 1, 2. The team briefly discusses why one person voted 2 - they'd noticed the same email template is used in three languages, so the fix needs to happen in three places, not one. Second vote: unanimous 2.

Shorter example: a medium feature

Story: "Add CSV export to the reports page." Votes: 5, 8, 5, 5. The person who voted 8 flags that the export needs to handle a report with 50,000+ rows without timing out, which the others hadn't considered. After discussion, the team settles on 8 and adds a note to check performance with a large dataset during implementation.

Shorter example: a large, vague story

Story: "Support multiple currencies throughout the app." Votes: 13, 21, 40, 8. The spread is huge, and the discussion reveals why: nobody agrees on scope - does it include historical order data, tax rules per region, and third-party payment provider support? The team doesn't force a number. Instead, they park the story, write down the open scope questions, and split it into smaller stories to estimate separately next session.

Try Fibopoker free

Try Planning Poker with your team - create a session and estimate your own backlog in minutes.

Start a free session