5 Tips for Introducing Planning Poker to a Brand New Team

“Planning Poker Is a Waste of Time”… If You Introduce It Badly

You’ve probably heard this in your team:
“Why are we arguing about 3 vs 5 points? This is pointless.”

Planning Poker can feel like a ceremony for ceremony’s sake. A 2022 State of Agile survey found that over 50% of teams still struggle with estimation, despite using tools like Planning Poker, story points, and Fibonacci sequences.

The problem usually isn’t the technique.
The problem is how it’s introduced.

If you roll Planning Poker into a brand new team without a clear purpose, shared rules, and strong facilitation, you’ll get:

• Endless debates about numbers
• Senior devs dominating the conversation
• Quiet people disengaging
• “Estimation fatigue” and fake consensus

Here’s how to introduce Planning Poker to a brand new team so it actually improves shared understanding and predictability—instead of becoming yet another meeting everyone dreads.

---

1. Start With “Why Estimation Exists” (Not With Fibonacci Cards)

Most teams jump straight to “Here’s how Planning Poker works” and completely skip the purpose.

1.1 Explain What Estimation Is Really For

Estimation is not about predicting the future with precision. It’s about:

• Comparing work items: Is this story bigger or smaller than that one?
• Surfacing unknowns: What do we not understand yet?
• Creating a shared mental model: Does everyone picture the same solution?

When introducing Planning Poker, say this out loud:

“We’re not trying to be perfectly accurate. We’re using Planning Poker to uncover misunderstandings early and align on relative complexity.”

This one sentence reframes the whole exercise.

1.2 Make a Clear Call on What Points Represent

One of the fastest ways to derail a new team is being vague about what story points mean.

Your choices:

• Relative size / complexity (most common)
• Time-based (e.g., ideal hours) – I strongly recommend against this
• Risk + complexity + effort combined

Pick one and be explicit. For most teams, something like this works:

“Points represent relative complexity and effort, including unknowns and risk—not hours. A 5-point story should feel roughly twice as complex as a 2-point story.”

Then give three concrete anchor examples from your own backlog:

• “This simple copy change = 1 point”
• “This small backend API change = 3 points”
• “This new feature with 2–3 unknowns = 8 points”

Without these anchors, Planning Poker turns into “vibes-based” estimation.

---

2. Design the First Session as a Workshop, Not a Meeting

Your first Planning Poker session should feel like a hands-on workshop, not a recurring ceremony you’re stuck with forever.

2.1 Limit the Scope: 6–10 Stories Max

Don’t try to estimate the entire backlog. For a brand new team:

• Pick 6–10 stories that are:
  • Well-written enough to discuss
  • Representative of different sizes
  • Relevant to the upcoming sprint or milestone

This keeps the session under 60–90 minutes and avoids “estimation fatigue.”

2.2 Set Ground Rules Up Front

Put these rules on a shared screen or whiteboard:

• Everyone votes every time
• No discussion until after cards are revealed
• The goal is understanding, not “being right”
• Disagreement is a signal, not a problem

Then say explicitly:

“If we’re stuck between 3 and 5, we won’t argue for 20 minutes. We’ll pick one, note the risk, and move on.”

That one rule alone can save you hours over a month.

2.3 Script the First Round or Two

For a brand new team, script the first couple of stories so people see the pattern. For example:

1. Product Owner (or someone) reads the story and acceptance criteria.
2. Team asks clarification questions (2–5 minutes max).
3. Everyone picks a card silently.
4. Facilitator says, “3…2…1… show.”
5. If all numbers are close (e.g., 3, 5, 5), ask:
   • “Anyone feel strongly about their number?”
6. If there’s a wide spread (e.g., 2, 5, 13), ask:
   • “Let’s hear from the highest and the lowest first—what assumptions are you making?”

Run this exact script for the first few stories until the team gets the rhythm.

---

3. Use Disagreement as Your Primary Signal

If everyone always picks the same number, you’re not estimating—you’re rubber-stamping.

3.1 Focus on the Outliers, Not the Average

When you see a spread like 2, 3, 8, 13, don’t ask, “What’s the right number?”

Ask:

• “What did you assume that led you to 13?”
• “What did you assume that led you to 2?”
• “What’s different in your mental models?”

You’re not trying to find mathematical consensus; you’re trying to:

• Uncover hidden work (e.g., migration, refactoring, testing complexity)
• Expose dependencies (e.g., “We need the data team to do X first”)
• Reveal gaps in understanding (e.g., “I thought we already had that API”)

3.2 Timebox the Debate Ruthlessly

Debating 3 vs 5 for 15 minutes is pure waste. Use this rule:

• If you can’t reach a decision in 5 minutes, do one of:
  • Split the story
  • Spike the unknowns
  • Pick the higher estimate and move on

You will be wrong sometimes. That’s fine. The point is to be consistently wrong in a way that lets you improve predictability over time.

---

4. Common Mistakes When Introducing Planning Poker (What Not to Do)

Planning Poker fails not because the technique is flawed, but because it’s misused. Avoid these traps from day one.

4.1 Letting Senior People Anchor the Room

If the most experienced dev or architect speaks first, everyone else will unconsciously adjust to them. This is anchoring bias, and it kills honest estimation.

What not to do:

• “Let’s go around and share what we think before voting.”

What to do instead:

• Use tools or cards that hide votes until everyone has chosen
• Explicitly say:

  “We’ll all vote silently and reveal together to avoid anchoring.”

4.2 Turning Points Into Performance Metrics

Nothing destroys estimation faster than using story points to measure individual performance.

If your team hears:

• “Why did you only complete 8 points this sprint?”
• “Alice delivered 30 points, Bob only 13…”

They will:

• Inflate estimates
• Game the system
• Stop being honest about complexity

Make this non-negotiable:

“Story points are for forecasting at the team level, not for evaluating individuals.”

4.3 Estimating Garbage Stories

Estimating poorly defined work is like measuring fog with a ruler.

Red flags a story is not ready:

• Vague titles: “Improve performance”
• No acceptance criteria
• Multiple outcomes mixed into one story
• Hidden dependencies no one has checked

Introduce a rule:

• “If we can’t explain what ‘done’ looks like in under 2 minutes, we don’t estimate it yet.”

4.4 Estimating Everything, Forever

Not everything deserves a Planning Poker session.

• Tiny tasks? Just call them 1 or 0.5 and move on.
• Bugs? Consider using a simple “small/medium/large” or time-box instead.

Use Planning Poker where it pays off most:

• New features
• Complex changes
• Risky or cross-team work

---

5. Practical Tips to Make Planning Poker Actually Useful

Here’s how to turn Planning Poker from a ritual into a real decision-making tool.

5.1 Define a Simple Scale—and Stick to It

Don’t overthink the numbers. Use a standard sequence like:

• 0, 1, 2, 3, 5, 8, 13, 20

And define rough guidelines:

• 1–2: Trivial or small change, well understood
• 3–5: Normal story, some moving parts
• 8–13: Large or risky, potential to split
• 20+: Too big; must be broken down

Use this explicitly in your first few sessions:

“If we’re about to give something 20, let’s first ask: can we split this into smaller, independently valuable pieces?”

5.2 Start With One Consistent Facilitator

For a brand new team, don’t rotate facilitation too early. Have one person (often the Scrum Master) own:

• Keeping the pace
• Watching the timebox
• Enforcing the “no discussion before reveal” rule
• Asking the right questions when there’s a spread

Later, you should rotate facilitation to build shared ownership—but not in your first 2–3 sessions.

5.3 Track Velocity—but Don’t Worship It

After 3–4 sprints, you’ll start to see a pattern:

• “We complete around 25–30 points per sprint.”

Use that for forecasting, not for pressure:

• “If we maintain ~25 points per sprint, we can roughly expect to finish these 60 points in about 2–3 sprints.”

Then refine as you go:

• If you consistently complete fewer points than planned, ask:
  • Are we overestimating our capacity?
  • Are we underestimating complexity?
  • Are we getting blocked by dependencies?

This is where Planning Poker pays off—not in the first session, but in the learning cycle over time.

5.4 Use Real Data to Improve Your Estimation

Once you have 4–6 sprints of data, run a short retro on estimation:

• Which stories were wildly overestimated?
• Which were wildly underestimated?
• What patterns do you see?

Example patterns:

• “Anything touching legacy service X is always bigger than we think.”
• “Integrations with external vendors always explode in complexity.”
• “UI-only changes are usually smaller than we fear.”

Turn these into new rules:

• “Any story touching legacy service X starts at 5 points minimum.”
• “Vendor integrations get a spike first, then we estimate.”

---

6. Make It Safe for People to Be Honest

The value in Planning Poker comes from people feeling safe enough to vote what they actually think.

6.1 Normalize Different Opinions

Say this explicitly in your first session:

“If we all always agree, it probably means we’re not thinking deeply enough. Different numbers are expected and helpful.”

Then reward dissent:

• When someone votes much higher or lower, thank them:
  • “Thanks for calling that out—what are you seeing that we might be missing?”

6.2 Use Tools That Reduce Social Pressure

In remote or hybrid teams, people can feel even more pressure to conform.

Use tools that:

• Allow anonymous or hidden voting until reveal
• Don’t require complex setup or accounts
• Make it easy for everyone to participate at the same pace

This reduces:

• Anchoring bias
• “Following the loudest voice”
• Awkwardness for juniors who see things differently

---

7. Tools and Logistics: Don’t Overcomplicate It

You don’t need a bloated tool stack to start, but you do need something that supports your process instead of fighting it.

7.1 Start Simple, Then Integrate

For a brand new team:

• In-person: Physical decks, whiteboard, sticky notes
• Remote: Lightweight online Planning Poker tools

Over time, integration with your existing workflow saves a lot of friction:

• Syncing estimates to your issue tracker (e.g., Jira)
• Keeping a history of estimates
• Reusing the same tool for retrospectives and planning

Tools like ScrumPoi make this painless: free for teams, anonymous voting by default to cut anchoring bias, no signup required for quick sessions, and Jira integration when you’re ready to wire it into your real workflow.

---

Conclusion: Planning Poker Is a Conversation Tool, Not a Number Generator

If you treat Planning Poker as a way to “get the right number,” your team will hate it—and they’ll be right.

If you treat it as:

• A structured way to expose assumptions
• A safe space for disagreement
• A learning loop to improve forecasting

…then it becomes one of the simplest, most powerful practices you can introduce to a brand new team.

Start by explaining why you’re doing it.
Keep the first session small and well-facilitated.
Use disagreement as a signal, not a problem.
And never, ever weaponize story points.

Do that, and Planning Poker stops being a waste of time—and starts being one of the few meetings your team actually finds useful.