The History of Planning Poker: From Cards to Digital

If you’ve ever sat in a refinement session where one person dominates the estimates and everyone else just nods along, you know how quickly estimation can go wrong.

Planning Poker was created to fix exactly that.

It’s simple, visual, and surprisingly powerful: everyone estimates at the same time, you reveal the cards together, and the conversation that follows is where the real value lives.

But Planning Poker didn’t just appear out of nowhere. It’s the result of a series of ideas evolving over time—from early estimation techniques, to physical card decks, to the digital tools many teams rely on today.

Let’s walk through that history and pull out practical lessons you can use with your team right now.

Before Planning Poker: The Estimation Problem

Before Planning Poker, most software teams used:

Hourly estimates (“This task will take 12 hours”)
Top-down estimates (a senior dev or manager guesses)
Big upfront planning (detailed Gantt charts, fixed dates)

These approaches had some common problems:

People treated estimates as commitments, not forecasts
Junior team members felt pressured to agree with seniors
Complex work was forced into oversimplified time boxes
Estimates were often wildly optimistic

Agile methods like Scrum introduced the idea of relative estimation: instead of asking, “How long will this take?” you ask, “How big is this compared to other work we know?”

That shift set the stage for Planning Poker.

Where Planning Poker Came From

Wideband Delphi and Relative Estimation

Planning Poker’s roots go back to the Delphi method, a structured way of gathering expert opinions. In the 1970s, it evolved into Wideband Delphi, where:

Experts independently estimate
Estimates are shared anonymously
Differences are discussed
The group iterates toward consensus

Sound familiar? That’s very close to how Planning Poker works.

Agile pioneers took this idea and combined it with story points and relative sizing. Instead of estimating in hours, teams started using abstract units (“points”) and comparing work against reference stories.

Enter Planning Poker: James Grenning & Mike Cohn

Planning Poker as we know it was first described by James Grenning in 2002 as a technique for XP (Extreme Programming) teams. It was later popularized by Mike Cohn, who trademarked “Planning Poker” and helped spread it through the Scrum community.

The core idea:

Use a deck of cards with values like 1, 2, 3, 5, 8, 13 (a modified Fibonacci sequence)
Everyone chooses a card privately
Everyone reveals simultaneously
Discuss differences, then re-estimate if needed

This solved several problems at once:

No one anchors the group with the first estimate
Quiet voices get equal weight
Outlier estimates trigger valuable conversations
The focus shifts from “being right” to “understanding the work”

The Era of Physical Planning Poker Cards

For many teams, the first Planning Poker sessions were delightfully low-tech: a deck of cards, a whiteboard, and some sticky notes.

Why Physical Cards Worked So Well

Physical Planning Poker cards brought a few unexpected benefits:

Tactile engagement: Holding cards, picking one, and placing it face down creates a small ritual that keeps people focused.
Simultaneous reveal: Everyone flips at once—no one has to go first.
Fun factor: It feels a bit like a game, which lowers tension around estimation.

A typical in-person Planning Poker session looked like this:

Pick a story
The Product Owner reads the user story and clarifies acceptance criteria.
Ask questions
The team asks about edge cases, dependencies, and risks.
Estimate silently
Each person picks a card (e.g., 3, 5, or 8 points) and places it face down.
Reveal together
Everyone flips their cards at the same time.
Discuss outliers
If someone picked 2 and someone else picked 13, they explain why.
Re-estimate if needed
After discussion, the team votes again, usually converging on a number.

Common Physical Deck Variations

Teams experimented with different card sets:

Modified Fibonacci: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100
T-shirt sizes: XS, S, M, L, XL
Special cards:
- ? for “I have no idea”
- ∞ for “This is huge / needs to be split”
- Coffee cup for “Let’s take a break”

These variations are still common in digital tools today.

Why Planning Poker Caught On in Agile Teams

Planning Poker spread quickly through Scrum and XP teams because it solved real, everyday problems.

It Encouraged Collaboration

Instead of a single “expert” estimating, Planning Poker:

Made estimation a team activity
Surfaced hidden assumptions
Encouraged cross-functional input (dev, QA, UX, ops)

It Made Estimation More Accurate (Over Time)

The goal of Planning Poker isn’t perfect precision; it’s shared understanding. But over time, teams noticed:

Fewer “surprise” tasks
More consistent velocity
Better forecasting for sprints and releases

Why? Because the conversations during estimation revealed risks, dependencies, and missing work.

Simultaneous reveal meant:

Juniors could safely disagree with seniors
Introverts didn’t have to fight to be heard
Strong personalities couldn’t dominate the estimate

The process itself enforced psychological safety, which is still one of its biggest benefits.

From Cards to Clicks: The Shift to Digital Planning Poker

As teams became more distributed, physical cards started to break down:

Remote team members couldn’t join easily
Hybrid teams struggled to keep everyone in sync
Whiteboards and sticky notes didn’t translate over video calls

Early Digital Experiments

At first, teams hacked together ad-hoc solutions:

Posting estimates in chat (which reintroduced anchoring)
Using shared spreadsheets
Asking everyone to DM their estimate to the Scrum Master

These approaches sort of worked, but they lost key benefits:

No clean simultaneous reveal
More manual coordination
Awkward for larger teams

Purpose-Built Digital Planning Poker Tools

To solve this, teams and toolmakers started building dedicated online Planning Poker apps, often integrated with:

Jira, Azure DevOps, or Trello
Video conferencing tools
Backlog management systems

Digital Planning Poker tools preserved the original mechanics:

Everyone selects a value privately
The facilitator “reveals” all estimates at once
Outliers are highlighted automatically
Teams can quickly re-vote after discussion

And they added new advantages:

Remote-friendly: Works across time zones and locations
Automatic tracking: Estimates saved to stories automatically
Customization: Different scales, card sets, or estimation modes
Analytics: Historical data on estimation and velocity

Practical Tips: Making Planning Poker Actually Work

The mechanics of Planning Poker are simple. The difference between “we tried it and it was a waste of time” and “this is one of our most valuable meetings” comes down to how you run it.

Here are practical tips you can use right away.

1. Set Clear Goals for the Session

Don’t estimate for the sake of estimating. Decide:

Are you sizing stories for the next sprint?
Are you doing high-level estimates for a roadmap?
Are you trying to identify risky or unclear work?

Knowing the purpose helps you:

Choose the right level of detail
Decide which stories to include
Timebox discussions appropriately

2. Prepare Stories Beforehand

Refinement shouldn’t be pure discovery. Before the session:

The Product Owner should:
- Write clear user stories
- Add acceptance criteria
- Identify obvious dependencies
The team should:
- Read the backlog items in advance (even briefly)
- Flag anything that’s obviously too big or unclear

This keeps the session focused on clarifying and sizing, not writing stories from scratch.

3. Timebox the Discussion

Planning Poker can easily turn into a rabbit hole. To avoid that:

Timebox each story (e.g., 5–8 minutes)
Use a simple rule:
- If you can’t estimate it within the timebox, it’s probably:
  - Too big → split it
  - Too unclear → Product Owner needs to refine more

You can also categorize stories:

Quick wins: Estimate now, move on
Needs more info: Capture questions, defer
Too big: Split into smaller stories

4. Focus on Outliers, Not Averages

If the estimates are 3, 3, 5, 3, 5, you probably don’t need a long debate.

But if they’re 2, 5, 13, that’s where the value is.

Use this pattern:

Ask the lowest and highest estimators to explain their thinking.
Encourage others to ask clarifying questions.
Re-estimate after a short discussion.

Often, you’ll discover:

Hidden complexity (edge cases, integrations)
Missing tasks (testing, deployment, UX work)
Misunderstandings about scope

5. Keep the Scale Simple

Don’t overcomplicate your point system. Common approaches:

Modified Fibonacci: 1, 2, 3, 5, 8, 13, 20
T-shirt sizes: S, M, L, XL for high-level estimates
“No hours” rule: Avoid mapping points directly to time

Whatever you choose, keep it:

Consistent across the team
Relative (“Is this closer to a 3 or an 8?”)
Decoupled from dates (points are about complexity/effort, not calendar time)

6. Make It Inclusive

As a Scrum Master or facilitator, watch for:

People always picking the same number as someone else
Certain voices dominating the discussion
Team members who rarely speak

Tactics to improve inclusion:

Explicitly ask quieter members, “What’s your perspective?”
Rotate who explains their estimate first
Use the chat for people who are more comfortable writing than speaking

7. Don’t Obsess Over Precision

Planning Poker is a forecasting tool, not a contract generator.

Avoid:

Arguing over whether something is a 5 or an 8 for 20 minutes
Trying to make every story exactly the same size
Treating estimates as commitments

Aim for roughly right, not perfectly precise. Over time, your velocity will stabilize and you’ll get better at forecasting without extra effort.

How Digital Planning Poker Changed the Game

Digital Planning Poker didn’t just copy the physical deck—it extended what was possible.

Benefits for Remote and Hybrid Teams

For distributed teams, digital Planning Poker:

Ensures simultaneous reveal even over video calls
Works across time zones (async options in some tools)
Reduces friction: no need to print cards, share screens awkwardly, or track estimates manually

Better Integration with the Rest of Your Workflow

Modern tools often:

Pull user stories directly from Jira or other backlog tools
Save estimates back automatically
Allow you to tag stories, leave comments, or attach notes from the discussion

This reduces admin overhead and lets you focus on the conversation.

Experimentation and Customization

Digital tools make it easier to:

Switch between point scales (Fibonacci, T-shirt, custom)
Try non-numeric options (e.g., risk levels, confidence scores)
Run parallel sessions with different teams

That flexibility lets you adapt Planning Poker to your team’s maturity and context, rather than forcing a one-size-fits-all process.

Putting It All Together: Best Practices for Modern Planning Poker

If you’re running Planning Poker now—or planning to introduce it—here’s a concise checklist you can use.

Before the session
- Product Owner prepares and prioritizes stories
- Team reviews the backlog beforehand
- You choose a simple, consistent estimation scale
During the session
- Clarify each story briefly (goal, scope, acceptance criteria)
- Timebox discussion per item
- Everyone estimates silently and reveals together
- Focus discussion on outliers (highest and lowest)
- Re-estimate if needed, then move on
After the session
- Capture key decisions and assumptions
- Note any stories that need splitting or more refinement
- Review how many stories you sized and whether the pace felt right
Over time
- Watch your velocity and adjust story sizes if everything feels “off”
- Refine your scale or reference stories as the team learns
- Regularly ask the team: “Is Planning Poker still helping us? How could we make it better?”

The Role of Tools Like ScrumPoi

You don’t need fancy software to start with Planning Poker, but digital tools can remove a lot of friction—especially for remote or hybrid teams.

Tools like ScrumPoi make it easy to run Planning Poker sessions with your team, keep everyone’s estimates in sync, and connect those estimates back to your backlog, whether you’re in the same room or spread across time zones.

Conclusion

Planning Poker started as a clever way to combine relative estimation, group wisdom, and a deck of cards. Over time, it evolved into a staple agile practice and then into a set of digital tools that support modern, distributed teams.

The mechanics are simple, but the impact is significant when you:

Treat estimates as conversation starters, not contracts
Focus on shared understanding instead of precision
Use the process to include every voice on the team

From physical cards on a conference room table to digital tools in a video call, the core purpose of Planning Poker hasn’t changed: align the team, surface assumptions, and make smarter decisions about the work ahead.

If you keep that purpose front and center, the specific cards—or apps—you use are just implementation details.

The History of Planning Poker: From Cards to Digital