Why the Fibonacci Point System is Terrible for Sprint Estimations

The Fibonacci Point System

We employ the following point system in our sprints to size feature complexity and estimate velocity. Each point builds upon the previous point’s complexity requirements.

• 1 — Small one line fixes, copy changes, or design tweaks.
• 2 — Small logic changes with potential regressions.
• 3 — Standard feature that often requires tracking and AB testing.
• 5 — Larger features than 3 that usually involve creating new screens and components.
• 8 — Very large feature that often requires significant refactoring or designing a new architecture.
• 13 — Epics. Projects that are too large to scope. Highly complex multi-sprint efforts that require significant planning and testing.

It’s a very common software industry standard to use Fibonacci pointing to estimate how much work we can accomplish within two-week sprints. Teams use estimations to determine sprint goals, calculate velocity and staffing needs based on burn-down charts, and plan quarterly roadmaps. Nevertheless as much as they try to estimate correctly, teams are always falling behind. From my experience, people end up not taking estimation seriously and even abandon it entirely.

It’s a common joke among developers to say,

“Oh just take whatever work you have to do and multiply it by 3.”