Agile Estimation with Fibonacci Numbers
Why do agile teams say "that's a 5" instead of "that's two days"? This guide explains Effort Points, relative estimation, and why the Fibonacci scale became the standard.
Try Planning Poker freeWhy Hour-Based Estimation Fails
"You want to visit your grandmother who lives 200 km away. How long will the drive take? Will you arrive by 7 pm? Can you guarantee you'll cover half the distance by 6 pm?"
Fixed scope
How long for the full drive?
Fixed deadline
Will you arrive by 7 pm?
Reality
Construction. Accidents. Detours.
Complex software works the same way. The more unfamiliar a task, the wider the error margin in any time estimate. What we can do is compare tasks to each other — which is the foundation of relative estimation.
What Are Effort Points?
Effort Points (or Story Points) don't represent hours. They represent relative effort compared to tasks you already understand. Each point combines three factors:
Complexity
How technically difficult or intricate is this task?
Uncertainty
How much still needs to be figured out or researched?
Volume
How much sheer work is involved, even if it's straightforward?
Why the Fibonacci Scale?
Notice how the gaps between numbers grow as they get larger. That's intentional — it reflects how estimation uncertainty actually works.
Small tasks: fine-grained
The gap between 1 and 2 is meaningful and distinguishable. Small differences in simple tasks matter.
Large tasks: coarse-grained
Nobody can reliably tell a 20-hour task from a 22-hour one. The scale reflects this — is it a 13 or a 21?
Teams stop debating "is this a 6 or a 7?" (there are none) and instead ask: "is this more like a 5 or more like an 8?" — a much more useful question.
Getting Started with Your Team
New teams often ask: "what does a 5 actually mean?" It means whatever your team decides — built through practice.
Pick an anchor task
Choose a small, well-understood backlog item everyone agrees is a "1" or "2". This becomes your reference point for everything else.
Estimate relative to the anchor
For each new item ask: Is this bigger or smaller than our anchor? By how much? The comparison is what matters.
Don't convert to hours
Resist saying "a 5 means two days." The whole point is to decouple effort from calendar time.
Let velocity emerge
After 2–3 sprints you'll know how many points your team completes per sprint. That's your velocity — a far more honest planning tool.
Split anything above 13
If an item scores 13 or higher, it's almost certainly too large for one sprint. Break it into smaller stories first.
Team Exercise: Lego Estimation
Makes relative estimation tangible without any code. Great for workshops, team onboarding, or any time you want a team to feel agile estimation rather than just read about it.
You need:
- 🧱 Lego bricks or building blocks
- ⏱️ Timer — 15 min per sprint
- 🃏 Planning Poker cards or tool
The tasks (hardest last):
- Simple small house
- House with garden & fence
- Two-story house
- A car
- A bus
How it runs: Before each sprint, estimate how many buildings the team can complete in 15 minutes using Planning Poker. Compare estimates vs. actual results. Teams quickly discover that relative comparisons are far more reliable than absolute time guesses — and experience first-hand why splitting large tasks matters.
Planning Poker: Estimate as a Team
The most widely used technique for assigning Effort Points. Here's why it works.
Simultaneous reveal
Everyone picks privately and reveals at once — no anchoring from the first person to speak.
Outliers surface knowledge
A lone 13 among a sea of 3s means someone knows something. The discussion that follows is the real value.
Fast
With a good tool, a team can estimate a full sprint's backlog in under 30 minutes.
Ready to run your first session?
The fastest way to learn estimation is to do it. Start free — no account, no setup.
Start a free Planning Poker session