Planning Poker with Non-Technical Stakeholders: A Complete Guide

One of the most valuable aspects of planning poker is bringing diverse perspectives together for better estimates. But what happens when your sessions include product owners, business analysts, marketers, or executives who don't speak the same technical language as your development team?

Planning poker with non-technical stakeholders transforms estimation from a purely technical exercise into a strategic conversation about value, priorities, and business impact. When done right, it bridges the gap between business vision and technical reality.

This guide shows you exactly how to include non-technical participants in planning poker sessions—with practical strategies for communication, simplified approaches, and techniques that focus on outcomes over implementation.

Why Include Non-Technical Stakeholders in Planning Poker?

Aligns Business Value with Technical Effort

When product owners participate in estimation, they gain firsthand insight into what features actually cost. A feature they thought would be "quick" might be an 8-point story, while something they assumed was complex might only be a 3.

This real-time learning drives better prioritization. Instead of asking "why does this take so long?" after development starts, stakeholders understand the effort upfront and can weigh it against business value.

Prevents Scope Creep Through Shared Understanding

Non-technical stakeholders often don't realize when they're adding scope. They might say "and while you're in there, can you also add..." without knowing that "while you're in there" could double the estimate.

When they hear developers explain what's involved during estimation, natural checkpoints emerge: "Does the estimate change if we skip the email notification for now?" These conversations happen in the moment, not mid-sprint.

Improves Requirement Clarity

Developer questions during estimation often reveal gaps in requirements that weren't obvious in the written user story. When the product owner is present, they can answer immediately. The team estimates based on complete information, not assumptions.

This back-and-forth—developers asking questions, stakeholders providing context—creates clearer requirements before any code is written.

Builds Trust and Transparency

When business stakeholders see the estimation process firsthand, they understand developers aren't pulling numbers from thin air. They witness the thoughtful discussion about complexity, dependencies, and edge cases behind each estimate.

This transparency transforms stakeholders from skeptics into partners in realistic planning.

The Challenge: Technical Jargon and Complexity

The biggest obstacle? Communication. Developers naturally discuss estimation in terms that alienate non-technical participants.

Common Communication Barriers

Technical terminology: "Refactoring the authentication layer," "handling edge cases in the state machine," "updating database migrations"—this language loses stakeholders fast.

Implementation focus: Technical discussions dive into "how" rather than "what." While necessary for accurate estimation, it excludes stakeholders who care about outcomes, not implementation.

Abstract story points: The concept itself confuses people. "Why use 1, 2, 3, 5, 8 instead of hours? What does an 8 really mean?" (Learn more about planning poker numbers here)

Different mental models: Developers think in code complexity and technical debt. Business stakeholders think in user value and market impact. These perspectives need translation.

Strategy 1: Focus on Value, Not Implementation

Frame estimation discussions around outcomes, not technical details.

Translate Technical Complexity to Business Impact

Instead of: "We need to refactor the authentication layer."

Say: "To add this login feature securely, we need to update our security foundation first. That's why it takes more effort than adding a simple button."

Connect every technical complexity to business outcomes. Answer: "Why does this matter for the product or users?"

Use "What" Language Before "How" Language

Structure discussions to start with outcomes:

1. What are we building? (Product owner explains)
2. What value does it provide? (Business context)
3. What defines success? (Acceptance criteria)
4. Only then: How complex is the implementation?

This keeps the conversation accessible while allowing necessary technical discussion.

Create a Shared Vocabulary

Replace jargon with plain language:

• "Edge cases" → "unusual situations we need to handle"
• "Technical debt" → "shortcuts we took before that now slow us down"
• "Refactoring" → "improving how the code works without changing what it does"

Document these translations so everyone uses consistent language.

Strategy 2: Simplify Your Estimation Scale

Not all scales work well with mixed audiences. Choose one that's accessible.

Consider T-Shirt Sizing for Mixed Groups

T-shirt sizes (XS, S, M, L, XL) beat Fibonacci for intuitive understanding. Everyone gets relative sizing from everyday life—small coffee vs. large coffee.

For mixed groups, T-shirt sizing reduces cognitive load while maintaining relative estimation benefits (compare with other methods here):

• XS: Very simple, obvious changes
• S: Straightforward work, clear path
• M: Moderate complexity, some unknowns
• L: Complex, requires coordination or new approaches
• XL: Very complex, probably needs breakdown

You lose some granularity versus Fibonacci, but gain accessibility.

Use Simplified Fibonacci

Prefer numbers? Try simplified Fibonacci: 1, 2, 3, 5, 8, 13. Drop the large numbers (21, 34, 55) and focus on the practical range (learn why we use Fibonacci).

Explain the scale as effort multipliers:

• 1: Minimal effort, very straightforward
• 2: Small effort, low complexity
• 3: Moderate effort, some thinking required
• 5: Significant effort, requires planning
• 8: Large effort, complex problem
• 13: Very large, should be broken down

Provide Reference Stories Everyone Understands

Create reference stories that resonate across roles:

1-point: "Adding a phone number field to the contact form"

3-point: "Creating a FAQ page using our standard layout"

5-point: "Implementing email reminders for upcoming events"

8-point: "Adding PDF export for reports"

Concrete examples help everyone calibrate understanding.

Strategy 3: Adapt the Estimation Process

Two-Tier Estimation: Business Value + Technical Effort

Some teams use a two-dimensional approach that separates concerns:

1. First round: Stakeholders estimate business value (High/Medium/Low or 1-5 scale)
2. Second round: Developers estimate technical effort using story points
3. Discussion: Compare dimensions to find high-value, low-effort wins and reconsider low-value, high-effort items

This gives stakeholders a clear role without requiring technical knowledge. It surfaces valuable conversations when value and effort don't align.

Stakeholder Estimates "Value Weighting"

Alternatively, have stakeholders focus solely on relative business value:

• They rank or weight stories by business value
• Developers estimate effort independently
• The team uses both dimensions for prioritization

This keeps stakeholders engaged without asking them to guess technical complexity.

Explain the "Why" Behind Estimates

When sharing estimates, developers should briefly explain reasoning in business terms.

Instead of: "This is an 8 because we need to refactor the API layer and update the ORM mappings."

Say: "This is an 8 because to add this feature reliably, we need to update how our system handles data. It's like renovating a room—you can't just paint the walls, you need to fix the foundation first."

Brief explanations help stakeholders understand without drowning in technical details.

Strategy 4: Establish Clear Roles and Boundaries

Define What Stakeholders Estimate vs. Provide Context For

Be explicit about roles from the start.

Stakeholders ARE responsible for:

• Explaining what needs building and why
• Clarifying business requirements and user needs
• Answering questions about scope and priorities
• Providing business context and constraints
• Estimating business value (if using two-tier estimation)

Stakeholders are NOT responsible for:

• Estimating technical implementation effort
• Deciding how to build something technically
• Understanding code architecture
• Defending developers' effort estimates

This clarity prevents stakeholders from feeling pressure to estimate technical work they shouldn't.

The Product Owner as Translator

The product owner bridges the gap in mixed sessions:

Before: Translates business needs into clear user stories with technical context

During: Translates technical questions into business terms and vice versa

After: Communicates outcomes in terms both sides understand

Invest in your product owner's bilingual fluency—business and technical.

When to Include Stakeholders vs. Brief Them After

Not every session needs all stakeholders.

Include stakeholders when:

• Estimating high-priority features for the next sprint
• Working on strategic initiatives with business impact
• Stories have unclear requirements needing real-time clarification
• Significant business uncertainty exists about scope or priority

Brief afterward when:

• Estimating technical debt or infrastructure work
• Refining low-priority backlog items
• Discussion will be deeply technical with little business context
• Time constraints make large meetings impractical

This selective approach respects everyone's time.

Strategy 5: Communication Techniques for Inclusive Estimation

The "Five-Year-Old" Test

Could you explain this to a smart five-year-old or your non-technical friend?

This doesn't mean dumbing down—it means using analogies, concrete examples, and clear language.

Technical: "We need to normalize the database schema and update the foreign key relationships."

Accessible: "Our data storage is organized inefficiently. To add this feature, we first need to reorganize how we store information—like reorganizing a messy filing cabinet before adding new files."

Analogies That Bridge the Gap

Develop a repertoire of analogies:

Estimating effort: "Building this is like adding a room to a house. A 3 is adding a closet. An 8 is adding a whole bedroom with plumbing and electrical."

Technical debt: "Technical debt is like home maintenance. You can skip cleaning the gutters for a while, but eventually it makes everything harder and more expensive."

Complexity: "This feature seems simple—like asking for a cup of coffee. But the estimate is high because we need to source the beans, buy a coffee maker, and learn to use it first."

Tailor analogies to your audience—construction metaphors for some, cooking for others, business processes for executives.

Active Listening and Question Encouragement

Questions aren't interruptions—they're valuable contributions (learn more about handling disagreements).

When stakeholders look confused: Pause. "Does this make sense? What questions do you have?"

When using jargon accidentally: Immediately translate. "Sorry, 'API' means how our software talks to other software—like a translator between systems."

When discussions get too technical: Facilitators should intervene. "Let me summarize what this means for the feature: [business-focused explanation]"

Create a culture where saying "I don't follow" is welcomed, not embarrassing.

Strategy 6: Preparation Makes Perfect

Pre-Estimation Story Refinement

Don't bring raw stories to estimation sessions with stakeholders. Refine first:

1. Technical pre-review: Developers briefly scan for obvious technical issues
2. Requirements clarity check: Product owner ensures clear acceptance criteria and business context
3. Complexity flag: Mark stories needing extensive technical discussion vs. straightforward ones

Sessions then focus on meaningful discussion, not discovering basic story problems.

Pre-Session Briefing Document

For important sessions, send stakeholders a one-pager:

• Stories you'll estimate and their business context
• Key technical considerations (in accessible language)
• What you need from stakeholders (context, decisions, priorities)
• Session duration and agenda

Stakeholders come prepared with relevant context and questions.

Establish Estimation Conventions Early

At your first mixed session, spend 10 minutes on shared understanding:

• Explain what story points represent (effort + complexity + uncertainty, NOT time)
• Review reference stories with examples everyone understands
• Clarify the process: voting, handling differences, discussion timing
• Define each person's role

This upfront investment pays dividends throughout (get tips for running your first session).

Strategy 7: Handle Disagreements Constructively

When Business Expectations Don't Match Technical Reality

Scenario: A product owner says "This should be quick, it's just a button" but developers estimate it as an 8.

Destructive: Developers defensively explain complexity in jargon, or simply insist "it's an 8, trust us."

Constructive:

1. Acknowledge: "I can see why this looks simple—it's one button on the screen."
2. Explain: "Behind that button, we need to integrate with a new payment system, handle errors, and ensure security. It's like an iceberg—you see the small tip, but there's a lot beneath."
3. Explore alternatives: "If we need this faster, we could start with a basic version without error handling, but that's risky. Or use a simpler approach that limits functionality. What's most important?"

This validates the stakeholder's perspective while educating, then collaboratively explores options.

The "High Estimate" Conversation

Frame high estimates as opportunities:

Instead of: "It's an 8, take it or leave it."

Say: "Our estimate is an 8, higher than we'd all like. This tells us:

• The feature as described is complex because of X and Y
• We might want to break it into smaller pieces
• There might be a simpler approach if we adjust requirements
• This might not be the right priority given the effort

Let's discuss which direction makes the most business sense."

Estimates become strategic conversations, not confrontational negotiations.

Using Estimates to Drive Better Decisions

Estimates reveal:

• Which features have the best value-to-effort ratio
• Where requirements need simplification
• When to explore alternative approaches
• What work needs breakdown

When a product owner sees Feature A estimated at 3 and Feature B at 13, but both have similar business value, they can make informed priority decisions. Estimates become planning tools, not just numbers.

Real-World Examples: What Works in Practice

Example 1: SaaS Company with Executive Involvement

Situation: Executives didn't understand why features took longer than expected.

Approach:

• Monthly "strategic estimation" sessions for high-priority features
• T-shirt sizing instead of story points
• Business analogies for explaining estimates
• "Translation guide" mapping technical terms to business concepts

Result: Executives gained realistic expectations. When requesting new features, they'd ask "is this small or large?" Prioritization improved because they weighed business value against understood effort.

Example 2: Enterprise Team with Distributed Stakeholders

Situation: Multiple departments (marketing, sales, support, finance) wanted roadmap input.

Approach:

• Two-tier estimation: stakeholders estimated value (1-5), developers estimated effort
• Online planning poker tool for remote participants
• Recorded sessions for those who couldn't attend
• "Estimation summaries" explaining business implications

Result: Engagement increased because stakeholders had a clear role without needing technical knowledge. Cross-functional prioritization improved with visible value and effort dimensions.

Example 3: Startup with Non-Technical Founders

Situation: Non-technical founders slowed estimation with basic questions.

Approach:

• "Planning Poker 101" document for founders
• Reference stories based on delivered features
• Explaining any estimate over 5 in plain language
• Simplified scale: 1, 2, 3, 5, 8
• Founders asked "Why is this complex?" rather than estimating

Result: Founders developed intuition over time. Their questions surfaced important product decisions earlier. The team felt respected because the process acknowledged different expertise.

Tools and Techniques for Remote and Hybrid Teams

Choose Accessible Digital Tools

For non-technical participants, your digital tool should be:

Immediately intuitive: No complex setup. Stakeholders join with a link and start participating within seconds.

Visually clear: Large voting buttons. Clear indication of who's voted. Easy-to-read results.

Minimally technical: Avoid developer-looking tools. Choose clean, approachable interfaces.

Planning Poker offers an accessible interface for diverse teams, with anonymous joining for guest stakeholders, customizable card sets including T-shirt sizing, and real-time visibility regardless of technical background (compare tools here).

Best Practices for Remote Stakeholder Inclusion

Use video: Non-verbal cues help gauge understanding and engagement (learn remote best practices).

Assign a facilitator: Someone watches for confused expressions or raised hands.

Use the chat: Encourage questions in chat during technical discussions. Address during natural pauses.

Provide screen share: Show the planning poker tool prominently so remote participants see all votes and discussions.

Record sessions: Stakeholders who can't attend watch later at 1.5x speed for key discussions.

Asynchronous Estimation for Global Teams

When time zones don't align, try asynchronous estimation:

1. Written story briefs: Product owner writes detailed descriptions with business context
2. Async voting rounds: Team members submit estimates within a 24-hour window
3. Discussion thread: Outlier estimates trigger written explanations
4. Sync for resolution: Only meet synchronously when written discussion doesn't resolve disagreements

More structure, but more inclusive than 3 AM meetings.

Measuring Success: How to Know It's Working

Qualitative Indicators

Stakeholders ask better questions: Instead of "why does this take so long?" they ask "what's making this complex?" or "could we simplify requirements to reduce effort?"

Fewer mid-sprint surprises: Stakeholders stop being surprised by timelines because they understood estimates upfront.

More trust: Business stakeholders express confidence in estimates rather than skepticism.

Better requirements: Stories from mixed estimation sessions have fewer clarification questions during development.

Collaborative problem-solving: When estimates are high, stakeholders work with the team to find alternatives rather than pushing back.

Quantitative Metrics

Estimate accuracy: Track whether estimates with stakeholder involvement are more accurate than technical-only estimates. Compare planned vs. actual effort (learn what metrics to track).

Rework reduction: Measure how often requirements change mid-development. Mixed estimation often reduces rework by clarifying upfront.

Meeting efficiency: Track session duration and stories estimated per hour. Well-run mixed sessions stay efficient.

Stakeholder satisfaction: Survey stakeholders about their understanding of development effort and satisfaction with prioritization.

Story refinement time: If stakeholder involvement reduces separate refinement sessions, that's a win.

Continuous Improvement

Use retrospectives to ask:

• "How well are we including non-technical stakeholders?"
• "What communication barriers still exist?"
• "Where did stakeholder involvement add the most value?"
• "What could make estimation more accessible?"

Treat inclusive estimation as a skill to continuously develop, not a one-time fix.

Common Pitfalls and How to Avoid Them

Pitfall 1: Stakeholder Overreach

Problem: Business stakeholders tell developers what estimates "should be" or argue technical complexity doesn't matter (avoid these common mistakes).

Solution: Reinforce role clarity. "We need your expertise on business value and requirements. The development team brings expertise on implementation effort. Both are essential." If overreach continues, have a private conversation about respecting technical expertise.

Pitfall 2: Dumbing Down Too Much

Problem: Oversimplifying loses technical nuance, making estimates less accurate.

Solution: Find balance. Translate concepts to business impact, but don't skip important technical considerations. It's okay to say "There's a complex technical reason this is harder—I'll explain at a high level, but trust we've thought through the details."

Pitfall 3: Estimation Becomes Sales Pitches

Problem: Stakeholders use estimation time to lobby for priorities, slowing the process.

Solution: Have a separate prioritization session. Estimation is about understanding effort, not arguing for priority. Facilitators should redirect: "That's valuable for prioritization. For now, let's focus on estimating effort if we build this."

Pitfall 4: Technical Team Resentment

Problem: Developers feel stakeholder involvement slows estimation or questions their expertise.

Solution: Show the value. Point out when stakeholder questions led to better requirements, prevented rework, or improved priorities. If resentment persists, the team needs to see concrete benefits.

Pitfall 5: False Precision

Problem: Stakeholders interpret estimates as commitments or expect exactness (learn what to do when estimates are wrong).

Solution: Repeatedly reinforce that estimates are educated guesses based on current understanding. Use "our current estimate is..." and "based on what we know now..." Estimates guide planning but aren't promises.

Getting Started: Your Action Plan

Week 1: Preparation

1. Identify stakeholders: Start with product owners or business analysts who work closely with the team
2. Choose your approach: Pick your estimation scale (Fibonacci, T-shirt sizes, or simplified numbers) for your audience
3. Create reference stories: Develop 3-5 examples that translate to non-technical language
4. Prepare your team: Discuss how to explain technical complexity in accessible terms

Week 2: First Mixed Session

1. Start small: Invite one or two stakeholders for a few high-priority stories
2. Set the stage: Spend 10 minutes explaining process, scale, and roles
3. Facilitate actively: Watch for confusion, jargon, or disengagement. Intervene to translate
4. Gather feedback: Ask what worked, what was confusing, what would help

Week 3: Refine and Expand

1. Adjust: Modify based on feedback
2. Document: Write down analogies and translations that worked
3. Expand: Invite more stakeholders or estimate more stories
4. Measure: Track whether requirements are clearer, rework reduced, understanding improved

Week 4: Establish the Practice

1. Create cadence: Decide when stakeholders routinely join (weekly sprint planning, monthly roadmap estimation)
2. Train facilitators: Ensure they're skilled at bridging communication gaps (tips for facilitators)
3. Build feedback loop: Use retrospectives to improve
4. Celebrate wins: Share stories when stakeholder involvement led to better decisions

Moving Forward: Building Bridges Through Estimation

Planning poker with non-technical stakeholders is about building bridges—between business and technology, between "what we want" and "what it takes," between different expertise areas that must collaborate.

When done right, inclusive estimation transforms planning poker into a strategic conversation. Business stakeholders gain realistic understanding of technical complexity. Developers gain deeper insight into business priorities and user needs. The team develops shared language and mutual respect.

The goal isn't perfect estimates—it's shared understanding. Every question a stakeholder asks, every analogy that clicks, every moment when technical complexity becomes clear in business terms builds that understanding.

Start small. Invite one product owner to one session. Try T-shirt sizing for accessibility. Create one good analogy that explains complexity. Build from there.

The communication skills your team develops through inclusive estimation serve you far beyond planning poker. Daily conversations improve, requirements become clearer, and the partnership between business and technology strengthens.

Ready to bridge the gap? Modern tools like Planning Poker make it easy to run inclusive sessions with features for diverse teams—simplified card sets, intuitive interfaces anyone can use regardless of technical background.

According to research from the Scrum Alliance, teams that include stakeholders in estimation see 30% better alignment between business priorities and development work. With patience, clear communication, and inclusive practices, you can create sessions where everyone contributes their expertise to build better products together.