What needs to be finished first
Acceptance criteria exist for every item to estimate, so scope and Definition of Done are clear.
What needs to be ready before start
Estimation tool (Planning Poker, Miro, Linear/Jira with Story Point field); visible reference-story list; scale poster (typically Fibonacci 1, 2, 3, 5, 8, 13, 20); backlog items with description and criteria.
One moderator (Scrum Master or Tech Lead); one Product Owner for scope; implementing team (3-9 people); one scribe for assumptions if needed.
Reference stories from real delivery history with assigned points; shared scale definition (for example "1 = trivial, 13 = larger story under splitting suspicion"); Definition of Done.
1-5 min per item, typically 60-90 min for refinement session
Reference stories visible as anchors on wall or board (for example "3 = SSO Google, 5 = API endpoint client export, 8 = self-service portal slice"). Scale poster. State rule: points include scope, complexity, risk and uncertainty, not only time.
The one question this method answers
How large is this item relative to our reference stories, considering scope, complexity, risk and uncertainty?
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Calibrate reference stories | 10 min | Walk through reference stories per point value. Team confirms or corrects. New team members get explanation for each value. | Without calibration, points are meaningless within team. When team changes (>30% new), reset references instead of keeping old ones. |
2Phase 2: Item estimation | 2-5 min per item | Present item, clarify questions, estimate (Planning Poker or direct). Points refer to relative size against reference, not hours. | If someone asks "how many hours is that?", method was not understood. Explain patiently: points are relative complexity unit, velocity later enables forecasting. |
3Phase 3: Split large items | 5-10 min per item | Mark items with 13+ points as splitting candidates. For each item, define proposal with owner and deadline. Items over 20 points do not enter sprint without split. | Large points are not wrong, but risky. Splitting reduces uncertainty and enables finer velocity forecast. If team cannot split, solution understanding is unclear. |
4Phase 4: Velocity evaluation | 10 min | After sprint end, document completed points per sprint. Use velocity of last 3-5 sprints as range (for example "22-31 points/sprint"). Forecast with this range, not with average. | Velocity is team-internal. Never use it to compare teams, otherwise points inflate. Recalibrate velocity trend after team change or tech migration. |
What comes out at the end
Backlog items in ticket system with Story Point field, reference-story list in wiki, velocity history as simple chart per sprint, splitting agreements per large item.
Story Points maintained per item. Re-estimation as comment with date and reason. Velocity history as sprint log with point sum and sprint date. Reference-story list with change date.
Compact working template for Story Points with context, input, output artifacts, and next step.
Relative unit for estimating scope, complexity, risk, and uncertainty of backlog items.
When and for what do we use this method?
Which data, observations, decisions, or materials are available?
Short notes along the runsheet.
Owner, date, and success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
Scale: 1, 2, 3, 5, 8, 13, 20
Reference stories
Sprint 22 refinement
Velocity (last 4 sprints): 24, 28, 26, 31. Range 24-31, forecast for Sprint 23 with lower value (24) as commitment, upper (31) as stretch.
Recognize symptoms and steer against them
Stakeholder asks "how many hours is one point", team answers, method becomes time estimation with colored paper.
Defend points as relative complexity. Time forecasts come from velocity range, not point-to-hour conversion. Stakeholder education once per quarter.
Management compares velocity of two teams ("Team A delivers 30, Team B only 20"), pressure for point inflation emerges.
Points are team-internal. Comparison makes no sense and produces inflation. Educate management and keep velocity reporting internal.
Nobody can say what a "5-point story" looks like anymore, estimation becomes gut feeling.
Review and update references quarterly. Earlier after team change. Choose references from real delivery history, not theory.
Velocity average becomes delivery commitment, team under pressure during normal sprint fluctuation.
Communicate velocity as range, not point value. Forecasts with percentiles (for example "85% probability to finish in 4 sprints"). Accept fluctuation as normal.
Points are assigned to people, individual velocity measured.
Points are team property, not personal. Measuring individual velocity destroys team estimation and leads to gaming.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.