Non-technical team members can take part in planning poker in one of two ways. Team members who do part of the work, such as designers, QA, content writers, and analysts, should vote, because story points size the whole team's effort, not just the code. Product managers and stakeholders who don't build the item usually shouldn't vote on effort, but they should be in the room to answer scope questions, because their answers change the estimate more than anyone's card.
The rest of this guide covers how to explain story points without jargon, a role table for who votes on what, and scripts for both the non-technical participant and the engineers.
Who votes, who advises
The Scrum Guide says the Developers who will do the work are responsible for sizing it. "Developers" there means everyone on the Scrum team who builds the increment, not just programmers. That gives you a simple rule:
| Role | Votes on effort? | Main job in the session |
|---|---|---|
| UX/UI designer on the team | Yes | Size design work inside the story; flag missing states (empty, error, loading) |
| QA / test engineer | Yes | Size testing effort; flag test data, devices, regression risk |
| Technical writer, content designer | Yes, for stories that include their work | Size docs, copy, localization |
| Data analyst on the team | Yes, for stories with analytics work | Flag tracking, dashboards, data quality |
| Product owner / product manager | Usually no | Explain the "why," answer scope questions, decide trade-offs on the spot |
| Business stakeholder, sales, support | No | Supply constraints: deadlines, compliance, customer impact |
| Engineering manager visiting the session | No | Listen. Votes from managers tend to anchor the team. |
Teams differ on whether the PO votes. If the PO also does hands-on work, such as writing acceptance tests or analytics specs, letting them vote is reasonable. If not, their vote mostly adds pressure. Agree on it explicitly instead of letting it vary from session to session.
If you're advising rather than voting, join as a spectator if your tool supports it. In Alignlee, for example, spectators see the stories and the revealed votes but aren't counted in the vote math, so a room full of observers doesn't skew the estimate.
Story points in plain language
When a PM asks "what's a 5?", don't explain Fibonacci. Try this:
"Points are a size comparison, not a time estimate. We pick a few finished stories we all remember, call one of them a 3, and size new work by asking 'bigger or smaller than that one?' A 5 is roughly 'noticeably bigger than our 3.' An 8 is 'big, with real unknowns.' A 13 usually means 'split it.'"
The numbers get further apart as they grow (1, 2, 3, 5, 8, 13...) because the bigger something is, the less precisely anyone can size it. Nobody can honestly tell an 11 from a 12. For the full background, see relative sizing with planning poker and story points vs hours.
Three things that confuse non-developers most:
- Points include uncertainty and risk, not just the amount of work. A change that takes an hour to type but touches billing might be a 5, because testing and risk are part of the size. See complexity vs effort.
- Points aren't comparable across teams. Team A's 5 isn't Team B's 5.
- Points aren't a commitment to a date. Dates come from velocity over several sprints, not from one estimate.
Use reference stories, not definitions
Abstract scales don't stick. Concrete memories do. Keep a short reference sheet, written in business terms, and show it at the top of every session:
| Size | Reference story (example) | Why it was that size, in plain words |
|---|---|---|
| 1 | Change wording on the signup button | One screen, no logic, trivial to test |
| 2 | Add a "company name" field to the profile page | New field saved and shown; a couple of screens to check |
| 3 | Email receipt after purchase | Uses an existing email system; a new template; test a few order types |
| 5 | Filter orders by date range | Front end, back end, and edge cases (time zones, empty results) |
| 8 | Sign in with Google | Third-party integration, security review, failure cases |
| 13 | Multi-currency pricing | Many systems, unknowns about rates and old data. Split before committing. |
Replace these with your team's own finished stories. The "why" column is what helps a non-technical person place new work.
If Fibonacci still feels abstract, T-shirt sizes (XS to XXL) are easier to grasp and work well for early or cross-functional sizing.
What non-technical people bring that engineers can't
The PM's most valuable contribution usually isn't a card. It's an answer that collapses a spread. When votes come back as 3 and 13, the gap is almost always a scope question, and the PM is often the only person who can answer it:
- "Does this need to work for existing customers, or only new signups?"
- "Do we need an audit trail for this?" (Compliance can double a story.)
- "Is the CSV export in scope, or a follow-up?"
- "Do support agents need to be able to undo it?"
- "Does it need to be live before the campaign on the 14th?"
Designers catch states nobody wrote down, like empty, error, loading, and permission-denied. QA catches the devices, browsers, and data setups that turn a 3 into a 5. That's why the role table puts them in the voting group.
Scripts
For the non-technical participant
You don't need to understand the code to help. Questions that reliably add value:
- "What would make this bigger than it looks?"
- "Is there a simpler version that would still solve the user's problem?" (This often turns an 8 into a 3 plus a follow-up story.)
- "What are the 3 and the 13 each assuming?"
- "Is anything here waiting on another team, a vendor, or legal?"
And one thing to avoid: don't suggest a number before the reveal. "This should be quick, right?" from a PM is the strongest anchor in the room. See how anchor bias affects planning poker.
For engineers explaining to non-technical colleagues
Give the impact first and the mechanism second:
| Instead of | Say |
|---|---|
| "We need to refactor the auth middleware" | "The login code needs reworking before we can add this. That's extra work underneath the feature." |
| "We'd have to denormalize the schema" | "We'd store the same info in two places for speed, which means more to test." |
| "We're blocked on the API contract" | "We need the vendor to confirm exactly what data they'll send." |
| "There's no test coverage there" | "That area has no safety net, so we'll test it by hand, slowly." |
Then ask: "Want more detail, or is that enough?" Let them choose how deep to go.
A worked example
Here's a hypothetical story: "Let customers download past invoices as PDF." Voters: three engineers, a designer, and QA. The PM is a spectator.
Round 1 votes: 3, 3, 5, 8, 13.
The facilitator asks the 13 (QA) and the 3 (an engineer) to explain:
- Engineer (3): "We already generate PDFs for receipts. Same library, new template."
- QA (13): "Invoices from before the 2024 billing migration live in the old system. Do those count?"
The PM answers: "Only invoices from the new system for now. Old ones are a separate story if customers ask."
The designer adds: "There's no page that lists past invoices yet, so we need one. Probably small."
Round 2 votes: 5, 5, 5, 5, 8. The team takes 5. The 8 (QA) notes extra test cases for invoices with refunds, and the team adds them to the acceptance criteria.
The PM didn't vote, but their one-sentence answer cut the story down more than any card did.
Onboarding a non-technical participant
Before their first session, send:
- The reference sheet above, with your team's real stories.
- One line on their role: "You're there to answer scope questions; you won't vote on effort" or "You'll vote on the design part of each story."
- The question list from the scripts section.
In the first session, estimate one known reference story together so they can watch the process before anything real is at stake. After three or four sessions, most people stop needing the sheet.
For stakeholder sessions outside software, such as marketing, HR, or operations, see agile for non-software teams.
Common mistakes
| Mistake | Fix |
|---|---|
| PM votes, and everyone defers to the PM's number | PM spectates and answers questions; decide this explicitly |
| Designers and QA excluded from voting | They're doing part of the work. They vote. |
| Engineers answer "why is it big?" with jargon | Impact first, mechanism only if asked |
| Stakeholder says "should be easy" before reveal | No numbers or adjectives before the cards are shown |
| Non-technical people forced to vote on pure infrastructure stories | Let them skip or spectate those stories |
| Converting points to days for stakeholders | Share forecasts from velocity across several sprints instead |
FAQ
Should non-technical team members vote in planning poker?
If they do part of the work, yes. Designers, QA, writers, and analysts on the team should vote, because story points size the whole team's effort. Product managers and stakeholders who don't build the item usually shouldn't vote on effort, but they should attend to answer scope questions.
How do you explain story points to a product manager?
Say they're a size comparison against stories the team has already finished, not a time estimate. Show a reference sheet ("the email receipt was a 3") in business terms, and explain that the scale gets coarser as items grow because big work is harder to size precisely.
Should the product owner vote on story points?
Usually not, because the product owner doesn't do most of the build work and their vote tends to anchor the team. If the PO does hands-on work such as writing acceptance tests, some teams let them vote. Pick a rule and apply it every time.
How can non-developers contribute to estimation?
By answering and asking scope questions: what's in and out, who it's for, what deadlines or compliance rules apply, and whether a simpler version would solve the problem. When votes split widely, a business answer is often what brings them back together.
What estimation scale is easiest for non-technical teams?
T-shirt sizes (XS to XXL) are the easiest to pick up because everyone already understands that L is bigger than M. Fibonacci points work fine too once the team has a reference sheet of past stories at each size.