Story Points and Planning Poker: A Worked Estimation Guide
与謝秀作
Story points express the relative size of work within a team. They can reflect effort, complexity, and uncertainty. A point value is not a fixed number of hours for a particular person.
Planning poker gives the people doing the work a structured way to compare estimates and uncover different assumptions. Start with a clear item such as a User Story Templates, rather than an unexplained task name.
Points and time answer different questions
Measure | Main question | Typical use |
|---|---|---|
Story points | How large is this compared with a reference item? | Comparing work and forecasting across cycles |
Time estimate | How many hours or days might this require? | Detailed planning and task breakdown |
Atlassian’s explanation of story-point estimation connects relative estimates with velocity. Fixing one point at eight hours removes much of the distinction. If a daily plan needs time estimates, create those separately.
Choose reference items
Use completed work that the team understands. The examples below are fictional, not a standard scale.
Reference item | Illustrative size | Included work |
|---|---|---|
Update existing explanatory copy | 2 | Check display and related links |
Add an optional field to an existing form | 3 | Check storage and display |
Add an unfamiliar external integration | Undecided | Investigate authentication and connection constraints first |
Do not hide every unknown inside a large number. An investigation or a smaller end-to-end slice can produce a more useful basis for planning.
Run a planning poker discussion
- Explain the item’s purpose, value, and acceptance criteria.
- Let the people doing the work ask about scope and dependencies.
- Each person independently selects a card, such as 1, 2, 3, 5, or 8.
- Reveal estimates together and discuss the highest and lowest assumptions.
- Estimate again, or choose investigation or splitting if understanding is still insufficient.
Agile Alliance’s planning poker guide explains the simultaneous reveal and discussion. The specific card sequence is a team choice. The purpose is shared understanding, not winning a guessing game.
When estimates differ
Suppose one person selects three because they expect a screen change. Another selects eight because they expect a storage change and migration. Averaging the values to 5.5 does not resolve the disagreement.
First determine whether migration is needed and which data it affects. If the answer is unknown, investigate before pretending that a precise estimate exists. A large spread is useful evidence that the team has different pictures of the work.
Use estimates without turning them into targets
Completed point totals support Agile Velocity. Keep the scale reasonably consistent and annotate deliberate changes. When selecting work, also consider leave, interruptions, dependencies, and the Sprint Goal. The Scrum Framework explains the wider framework.
New teams begin with provisional reference items and refine their understanding through experience. Estimates belong to the people doing the work; reducing a number to fit a requested deadline does not reduce the work itself.
For the surrounding campaign workflow, Xtrategy’s project management features connect task progress with cost and approval information. Keep those operational constraints visible alongside estimation discussions.