A Practical Planning Poker Example

This Planning Poker example shows how an Agile team can estimate a user story in practice. If you already understand the basics of Planning Poker but want to see how a real estimation discussion works, this example will help.

The user story in this example

Imagine a Scrum team discussing the following backlog item:

Before voting, the Product Owner explains the story, and the team asks a few questions:

• Do we already have email infrastructure in place?
• Do we need a secure token with an expiration time?
• Should the reset page work on mobile as well?
• Do we need analytics or audit logging for security purposes?

First round of votes

Once everyone understands the story, each team member privately selects a card. In this example, the team uses the Fibonacci sequence.

Why the estimates are different

This is normal. Planning Poker is designed to reveal different assumptions. In this example:

• The designer focuses mostly on the UI, so the story looks smaller.
• The developers think about tokens, email delivery and security.
• The QA engineer considers invalid links, expired tokens and regression tests.

Discussion after the reveal

After revealing the cards, the Scrum Master asks the team to explain the highest and lowest estimates first. The discussion uncovers a few hidden details:

1. The reset email needs a secure token with an expiry date.
2. The API must protect against abuse and invalid requests.
3. The team wants mobile-friendly screens and clear error states.
4. QA needs to test several security and usability scenarios.

At this point, everyone agrees that the initial estimate of 2 was too low. The story is not huge, but it is more than a simple form update.

Second round and final estimate

The team votes again after the discussion. This time the votes are:

The team agrees on a final estimate of 5 story points. This number reflects moderate complexity, some uncertainty, and the need for both frontend and backend work.

What this example teaches

A good Planning Poker session is not about getting the "perfect" number. It is about creating a shared understanding of the work. In this example, the real value of the session came from the discussion, not just the cards.

• Different roles notice different risks and dependencies.
• Hidden complexity becomes visible before development starts.
• The team reaches a more reliable estimate together.

Try your own Planning Poker example online

You can reproduce this exact flow with your own team using Poker-Planning.org. Create a room, invite participants with a link, vote with Fibonacci cards and reveal all estimates at the same time.