Planning Poker for Non-Technical Stakeholders
Having non-technical people in an estimation session can be valuable or destructive, depending on how it's set up. Here's how to get the value without the problems.
The core tension
Developers estimate technical complexity. Non-technical stakeholders often don't have the context to estimate the same dimension, but they do have context on business impact, edge cases, and requirements that the dev team might not know.
These are different kinds of knowledge, and mixing them in the same vote creates confusion.
Who should vote on what
Developers vote on technical complexity. This is what story points measure. A product manager shouldn't be voting on how hard it is to refactor the payment API. (Designers are a genuinely harder call.)
Stakeholders should answer questions, not vote. Their role in the session is to clarify scope, explain user behavior, and provide business context when the dev team asks, the same boundary that applies to the Product Owner.
When stakeholder participation helps
- They can answer "what happens if the user does X?" on the spot instead of the team waiting a day for the answer
- They can clarify competing requirements in real time
- They can make scope decisions when the team surfaces a fork ("do you want A or B?")
Setting expectations before the session
Brief stakeholders before their first session: "We want you in the room to answer our questions. You don't cast a vote. If you do, it's likely to be based on how long you want something to take, which is different from how complex it actually is."
Most stakeholders appreciate the honesty and the clear role.
When to exclude them entirely
Some teams find that stakeholder presence, even when they're not voting, creates social pressure that compresses estimates. If this is happening in your team, limit stakeholder access to the results, not the session.
The goal is accurate estimates. Design the session around that goal, not around including everyone.
