Estimating Poker is easy to memorise as a definition and harder to use in a real enterprise. This guide is designed to explain why collaborative relative estimation is a conversation about uncertainty rather than a productivity score.
What Estimating Poker and Relative Estimation mean in practice
Estimating Poker is a collaborative method for comparing the relative size of stories or features. Participants reveal estimates together, discuss meaningful differences, and estimate again if needed. The modified Fibonacci sequence spreads larger numbers because uncertainty grows as work becomes larger and less understood.
The common implementation mistake
Converting each story point into a fixed number of hours defeats relative estimation. Comparing velocity between teams then adds pressure without creating useful forecasting information.
A practical comparison
| Element | Purpose or question | Useful evidence |
|---|---|---|
| Reference item | A familiar completed item | Creates a shared comparison point |
| Independent choice | Each participant selects before discussion | Reduces anchoring on senior voices |
| Difference | High and low estimates explain assumptions | Hidden work and uncertainty become visible |
| Split | Large items are divided | Feedback arrives sooner and estimates become safer |
Worked enterprise example
Developers estimate a story as five while testing and security participants choose thirteen. The difference may reveal environments, data, or compliance work absent from the story. The conversation is more valuable than averaging the numbers.
How to apply the concept without creating ceremony
- Use a stable reference item.
- Include every skill needed to finish the work.
- Discuss outliers without forcing agreement.
- Split large uncertain items before detailed planning.
How the glossary terms connect
Estimating Poker, Relative Estimation, Modified Fibonacci Sequence, Story Point belong in the same conversation because an enterprise rarely experiences them separately. One term may describe a role or structure, another the decision being made, and another the evidence needed to inspect the result. Reading each definition independently can hide that relationship.
Measures and evidence to review
- Customer or stakeholder outcome affected by the change.
- Elapsed time, waiting, work in process, or decision delay.
- Quality, risk, compliance, or reliability evidence relevant to the context.
- A behaviour or policy that changed, not merely attendance at an event.
- An unintended effect on another team, value stream, or customer group.
Questions leaders and practitioners should ask
- What problem are we trying to solve with Estimating Poker?
- Which decision or behaviour should change?
- Who has the authority and knowledge required?
- What assumption is least certain?
- How will we know whether value flow improved?
- When will we inspect and adjust the approach?
Connection to SAFe learning
SAFe Scrum Master certification training provides a broader learning context for these decisions. Certification can establish shared language, but capability develops when learners apply the ideas to real work, inspect evidence, and receive support from leaders and peers.
Apply the concept to an operating decision
Relative estimation is a conversation about size, complexity, uncertainty and risk—not a conversion table for hours. Estimating poker can expose different mental models when participants reveal estimates together. The modified Fibonacci sequence makes false precision less attractive as uncertainty grows.
A practical review
Use a small reference set of completed stories and ask why estimates diverge. Split items when the discussion uncovers multiple outcomes, unknown interfaces or mixed work types. Review forecast accuracy at a group level and avoid using individual estimates for performance evaluation; that changes the behaviour being measured and damages the information.
