Scrum Poker Deck

Scrum Poker, also known as Planning Poker, is a consensus-based agile estimation technique created by James Grenning and popularized by Mike Cohn. Team members independently select cards from a modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 21...) to estimate the relative effort of user stories. Cards are revealed simultaneously to prevent anchoring bias — the tendency for early estimates to influence later ones.

The technique works because it leverages the collective wisdom of the team while avoiding groupthink. When estimates diverge significantly, the highest and lowest estimators explain their reasoning, leading to productive discussions that uncover hidden complexity, missing requirements, or differing assumptions about scope.

Planning Poker has become the most popular estimation method in Scrum and agile teams worldwide because it is quick, engaging, and produces more accurate estimates than individual expert judgment alone.

Traditional Scrum Poker tools require creating accounts, sending data through central servers, and trusting third-party infrastructure with your sprint planning data. Our approach eliminates all of these concerns with encrypted, ephemeral sessions.

All communication between participants happens over encrypted real-time connections. Room names, participant names, and estimation values exist only during the active session — when everyone leaves, everything disappears permanently. No accounts are needed and no data is stored.

This design is ideal for teams working with sensitive product roadmaps, proprietary feature specifications, or in industries with strict data handling requirements. Your estimation data is never stored permanently.

Before the session, ensure the Product Owner has prepared well-defined user stories with clear acceptance criteria. Ambiguous stories lead to wild estimation variance that wastes everyone's time. Share the room link with all participants and verify everyone has joined before starting.

For each story, the Product Owner presents it briefly, answers clarifying questions, and then everyone selects their card simultaneously. When cards are revealed, look for convergence — if most estimates are close (e.g., 5, 5, 8, 5), take the consensus value. If there is wide divergence (e.g., 2, 13, 5, 21), have the outliers explain their thinking before re-voting.

Limit discussion to 2-3 minutes per story. If the team cannot converge after two rounds, it usually means the story needs to be broken down into smaller, more estimable pieces. Use the reset round button to clear votes and re-estimate when needed.