Let's clear something up immediately: planning poker isn't just for developers. If your work touches the feature being built, your input makes estimates better.
Designers, product managers, QA engineers, technical writers, data analysts—you all catch things developers miss. This guide shows you exactly how to contribute without feeling lost.
Why Non-Developers Matter
Developers are amazing at estimating code. But features aren't just code. Here's the value you bring:
You bring user perspective
Developers focus on code. You focus on impact. That's the missing piece in most estimates.
Example: You know this "simple" button change affects 12 other screens. Developers might not.
You catch hidden work
Documentation, testing, design iterations, stakeholder reviews—work developers often forget to estimate.
Example: That API change needs design updates, QA test plans, and help docs. You'll spot it.
You ask better questions
Technical teams assume shared context. You don't. Your "dumb questions" reveal missing requirements.
Example: "What happens on mobile?" seems basic but often uncovers entire platforms they forgot.
You prevent scope creep
You know what stakeholders actually asked for versus what developers want to build.
Example: MVP vs. perfect solution. You keep the team honest about what's actually needed.
How to Contribute Effectively
Listen to the technical discussion first
Don't vote immediately. Let developers explain their approach. You'll learn the technical constraints.
Focus on your domain's complexity
Vote based on design iterations needed, testing scenarios, edge cases, or stakeholder complexity.
Speak up when you disagree
If your number is way off from the team, explain your reasoning. Often you're catching something they missed.
Ask clarifying questions freely
"What does that mean?" is a completely valid contribution. Unclear stories lead to bad estimates.
Translate technical work to user impact
Help the team connect effort to value. "This affects 50% of users daily" changes perspective.
Common Concerns (Addressed)
These worries come up constantly. Here's the honest truth about each one:
"I don't understand the technical parts"
The truth: You don't need to. Vote on the parts you DO understand—design complexity, testing needs, user impact.
Developers don't understand your domain either. That's why you're here.
"My estimates are always wrong"
The truth: Everyone's estimates are wrong. Planning poker averages out individual blind spots. Your perspective improves accuracy.
Wrong alone, right together. That's literally the point of the exercise.
"Developers ignore my input"
The truth: Good teams don't. If yours does, that's a team culture problem, not a you problem.
Your role is to raise concerns. Their job is to address them. Don't self-censor.
"I feel like I'm slowing things down"
The truth: Questions now prevent disasters later. Fast estimation with missing context leads to failed sprints.
If developers are rushing you, the process is broken, not your participation.
"I don't know what story points mean"
The truth: Neither does anyone else, honestly. They're relative complexity, not hours. Trust your gut.
If this feels twice as hard as the last story, vote twice the points. That's it.
Tips for Different Roles
Tactical advice based on your specific role in the team:
Designers
- •Vote on iteration cycles needed, not just design hours
- •Flag when designs affect multiple features or platforms
- •Speak up about brand consistency and design system impacts
- •Estimate stakeholder feedback rounds realistically
Product Managers
- •Keep the team focused on user value, not technical elegance
- •Raise red flags about unclear requirements or missing context
- •Vote based on stakeholder complexity and approval processes
- •Help prioritize must-haves vs nice-to-haves during estimation
QA / Testers
- •Vote high when you see complex edge cases or integration points
- •Speak up about regression testing needs and automation work
- •Flag stories that affect critical user flows or payment systems
- •Don't let developers underestimate testing and bug fix time
Technical Writers
- •Estimate documentation complexity, not just feature complexity
- •Flag features that need user education or onboarding flows
- •Raise concerns about API changes that affect external developers
- •Speak up when features introduce confusing UX that needs explanation
Data Analysts
- •Vote based on analytics instrumentation and tracking needs
- •Flag features that need new dashboards or reporting
- •Speak up about data privacy and compliance implications
- •Estimate A/B test setup and statistical significance timelines
DevOps / Infrastructure
- •Vote high on features that need new infrastructure or scaling
- •Flag deployment complexity and rollback requirements
- •Speak up about monitoring, alerting, and on-call implications
- •Don't let teams forget about security reviews and compliance
General Participation Tips
Vote from your perspective
Don't try to think like a developer. Vote based on YOUR domain's complexity. That's your unique value.
Questions are contributions
Every "stupid question" you ask potentially saves hours of rework. Ask everything that's unclear.
Start with relative sizing
Pick a simple story everyone agrees on. Use that as your baseline. "Is this harder or easier than that?"
Learn the lingo (slowly)
You'll pick up technical terms over time. Don't fake understanding—ask for plain English explanations.
Speak up when outliers
If your vote is way different from others, explain why. You might be seeing something they missed.
Focus on your domain's work
Estimate design time, testing scenarios, docs, compliance—the non-code work that makes features ship.
The Real Talk
Planning poker works best when everyone who touches the work has a voice. Developers know code. You know design, users, testing, documentation, infrastructure, analytics—all the things that make features actually ship.
Don't apologize for not understanding technical implementation. That's not your job. Your job is to represent your domain's complexity and catch the blind spots developers have in your area.
If a team makes you feel stupid for asking questions or participating, that's a culture problem, not a skills problem. Good teams recognize that diverse perspectives lead to better estimates.
Everyone's Voice Matters
Our planning poker tool works for technical and non-technical team members alike. Simple, inclusive, free.
Create Free Room