Guide

Agile estimation glossary

The vocabulary of planning poker, Scrum refinement, and agile estimation. Definitions are intentionally short — each is the practical meaning a working team uses, not the framework-purist definition.

Acceptance criteria
The conditions under which a user story is considered done. Acceptance criteria are written before estimation — without them, the team is sizing an undefined scope and the estimate is noise.
Anchoring bias
The cognitive tendency for people's numerical estimates to gravitate toward the first number they hear. Documented by Tversky and Kahneman (1974). Planning poker's simultaneous reveal is specifically designed to eliminate it.
Backlog
The ordered list of work items the team has yet to deliver. The product backlog is owned by the product owner and contains user stories, technical work, bugs, and spikes — typically sized in story points.
Backlog refinement
The ongoing activity of clarifying, splitting, and estimating backlog items so they are ready for sprint planning. Also called grooming. Planning poker is the most common estimation technique used during refinement.
Definition of done (DoD)
The team's checklist for what makes a story shippable — tests written, code reviewed, deployed to staging, documentation updated. Separate from acceptance criteria (which are per-story); DoD is per-team and applies to every story.
Epic
A large body of work that is too big to fit in one sprint and needs to be broken down into smaller user stories. Epics are not typically estimated with planning poker; their child stories are.
Estimation
The activity of forecasting effort, duration, or cost for a piece of work before it is done. In agile, estimation is intentionally rough — story points capture relative size, not duration, because precise effort prediction is impossible for novel work.
Fibonacci scale
The number sequence 1, 2, 3, 5, 8, 13, 21 used for story-point estimation. Each value is the sum of the two before it. The widening gaps mirror a real property of estimation: precision drops as work gets larger. See the dedicated guide on the Fibonacci scale in agile estimation.
Planning poker
A consensus-based estimation technique invented by James Grenning in 2002 and popularised by Mike Cohn in 2005. Each team member privately picks a card with their estimate; everyone reveals at once; if estimates differ, the gap is discussed and the team re-votes. Also called scrum poker — same technique. See the complete planning poker guide.
Reference story
A story the team has already delivered, used as the calibration anchor for sizing new stories ("the new story is about twice as big as our reference 3 — call it a 5"). New teams pick a reference story in the first sprint and refer back to it for 3-5 sprints until shared intuition develops.
Refinement
See backlog refinement.
Scrum poker
An alias for planning poker — same technique, different name. See planning poker vs. scrum poker.
Spike
A time-boxed research story used when the team does not have enough information to estimate the actual work. Spikes are sized in hours or days (not story points) because they are bounded by time, not effort.
Sprint
A fixed-length iteration in Scrum — usually one or two weeks — during which the team commits to deliver a slice of the backlog. Planning poker happens before the sprint, during sprint planning and backlog refinement.
Sprint goal
A one-sentence statement of what the sprint is trying to achieve, separate from the list of stories. The goal anchors prioritisation when scope must be cut mid-sprint.
Sprint planning
The meeting at the start of a sprint where the team commits to which backlog items will be delivered. Planning poker is often used here to size or re-size items that have not been refined yet.
Story point
A relative unit of effort that bundles complexity, uncertainty, and volume into a single number — popularised by Mike Cohn in 2005. Most teams estimate in story points using the Fibonacci scale. See story points explained.
T-shirt sizing
An estimation scale using sizes (XS, S, M, L, XL, XXL) instead of numbers. Useful for early-stage rough sizing before stories are broken down, when committing to a number would imply false precision.
User story
A short description of a feature from the user's perspective, traditionally in the form "As a [role], I want [action] so that [benefit]". User stories are the typical unit estimated with planning poker.
Velocity
The average number of story points a team completes per sprint. Velocity is a forecasting input — "we usually finish 30 points; this sprint has 28 planned, so it looks doable". Velocity is not a performance metric; treating it as one inflates estimates and degrades the signal.
Wideband Delphi
An iterative-convergence estimation method described by Barry Boehm in his 1981 book Software Engineering Economics. Wideband Delphi runs the same loop as planning poker (independent estimates → discuss outliers → re-estimate) but with written submissions and a moderator. Planning poker is its lightweight, card-based descendant.

Use the vocabulary

Run a planning poker session and put the terms into practice. Free, no sign-up.

Start a planning poker session