Agile Estimation and Velocity
1,2,3,5,8,13
Fibonacci Sizing
Story points grow non-linearly
3-5
Sprints to Stabilize
Velocity becomes reliable after several sprints
0
Hour Equivalents
Story points do not map to hours or days
fibonacci cards · big gaps force real conversations
Planning Poker Deck
how to read this
- › The numbers follow Fibonacci: 1, 2, 3, 5, 8, 13, 21. Gaps grow as stories get bigger — because larger estimates are less precise.
- › Every team member holds a full deck. Everyone picks a card privately, then reveals at the same time.
- › When people disagree, the outliers explain their thinking. This is where hidden assumptions surface.
- › 21 or higher = split it. A story too big to fit in a sprint is too big to estimate confidently.
- › ? and ∞are escape hatches. ? means "I have no idea," ∞ means "no way this fits our process."
Velocity Stabilization
how to read this
- › Early sprints are noisy. New teams, new tools, new domain — velocity swings wildly.
- › Wait 3–5 sprints before trusting velocity for release planning. Use a rolling average, never a single sprint.
- › Once stable, you can forecast: remaining backlog ÷ average velocity = estimated sprints to release.
- › Never use velocity to compare teams or judge individuals. That's the fastest way to poison the signal.
Exam Traps
Velocity belongs to the team, not the PM
Velocity is a planning signal owned by the self-organizing team. Using it to compare teams, reward individuals, or justify punishment is an anti-pattern the exam tests for.
Story points are not hours
A story point measures relative effort, not time. An 8-point story does not mean 8 hours or 8 days. Any answer that converts story points to a time unit is a trap.
Single-sprint velocity is unreliable
New teams, new tools, and new environments cause noise. Use a rolling average of 3 to 5 sprints before using velocity for release forecasting.
Planning Poker is consensus-based
Every team member estimates independently, then discusses. The PM or Product Owner does not override the team. If an answer has a manager assigning the estimate, it is wrong.
Relative, not absolute
Story points describe effort relative to other stories. Compare to a baseline story, do not translate to hours.
Do not weaponize velocity
Never use velocity for performance reviews or team comparisons. It kills the signal and poisons the team.
Picking up milk is small. Doing a full weekly haul is medium. Stocking up for a holiday dinner is large. You do not say "milk takes 7 minutes." You compare relative effort.
Over the last month you averaged 15 "shopping points" per week. That is your velocity. You can plan the next few weeks around it.
If you had the flu one week and only got 5 points, that is not your velocity. Take the average over several weeks.
A medium run and a large run both include unpredictable variables — traffic, out-of-stock items, long lines. You estimate effort, not clock time. Hours are a trap.
Ready to test your PMP knowledge?
1,800 practice questions written by certified professionals.
Start Practicing PMP