How to Use Fibonacci for Relative Sizing in Scrum

Here’s the gist: Scrum teams use Fibonacci-based story points to estimate tasks by focusing on Complexity, Uncertainty, and Effort (CUE), rather than time. The sequence (e.g., 1, 2, 3, 5, 8, 13...) reflects the growing unpredictability of larger tasks, helping teams make quicker decisions, avoid over-precision, and improve collaboration during planning sessions.

Key Benefits of Fibonacci in Scrum:

• Simplifies estimation: Larger gaps in numbers reflect increased uncertainty.
• Encourages teamwork: Outlier estimates spark discussions to align understanding.
• Improves task management: High estimates (13+) indicate tasks should be split into smaller pieces.
• Stabilizes velocity: Teams track progress more consistently over time.

Using tools like Planning Poker and reference stories ensures consistent, bias-free estimates. Follow a structured process: clarify the task, estimate privately, reveal estimates, discuss differences, and reach consensus. This method reduces wasted time and helps teams plan effectively.

Benefits of Using Fibonacci for Relative Sizing

Simplifying Complexity with an Exponential Scale

The Fibonacci sequence aligns perfectly with a core reality of software development: the larger the task, the harder it is to predict accurately. Unlike linear scales, which imply a similar level of precision across all tasks, Fibonacci introduces widening gaps as numbers grow. For instance, while the difference between 1 and 2 is just one point, the jump from 8 to 13 spans five points. This widening reflects the increasing uncertainty that naturally accompanies more complex work. Agile Specialist Abhay Talreja explains it succinctly:

"The larger the task, the less precise we can be. Fibonacci's widening gaps reflect this natural uncertainty."

Each number in the Fibonacci sequence is approximately 1.618 times the previous one, following the Golden Ratio. This progression encourages teams to focus on the inherent complexity of tasks rather than getting bogged down by false precision. By doing so, it creates a clearer framework for understanding task difficulty and fosters better collaboration.

Encouraging Team Collaboration in Estimation

The clarity of the Fibonacci scale transforms estimation into a team-centric activity. Instead of relying on individual judgments, it fosters group discussions. When team members provide differing estimates - say, one person suggests 3 while another proposes 8 - it highlights differing assumptions, potential risks, or alternative solutions. Tools like Planning Poker ensure that estimates are revealed simultaneously, reducing the risk of anchoring bias. This means junior developers won’t feel pressured to align with the opinions of senior team members.

When discrepancies arise, the team discusses the outliers rather than simply averaging the numbers. This dialogue often uncovers hidden complexities or reveals opportunities to simplify the task. As a result, the estimation process becomes a collaborative effort that brings everyone onto the same page.

Preventing Over-Precision and Improving Velocity

The Fibonacci approach also avoids the trap of over-precision. As OnlinePlanningPoker.com points out:

"The difference between 7 and 8 story points is meaningless, but the jump from 5 to 8 forces meaningful discussion about complexity."

This method not only speeds up estimation sessions but also leads to more consistent velocity tracking. When teams stick to the Fibonacci scale, their velocity - the total points completed in a sprint - stabilizes more quickly, making it easier to predict future workloads. Additionally, stories estimated at 13 points or higher often signal that a task is too big or poorly defined. This prompts the team to break it into smaller, more manageable pieces, reducing the risk of overcommitment and helping Scrum Masters identify pacing issues.

Aspect	Fibonacci Scale	Linear Scale (1-10)
Uncertainty Handling	Accounts for growing uncertainty with wider gaps	Implies equal precision across all levels
Decision Speed	Faster; encourages choosing distinct values	Slower; leads to debates over small differences
Large Task Management	Highlights the need to break down complex tasks	Can obscure the complexity of large tasks
Velocity Tracking	Stabilizes quickly for better forecasting	Often fluctuates due to inconsistent sizing

Preparing for Fibonacci Estimation Sessions

Defining Story Points and Relative Scales

Start by agreeing on what story points represent, using the CUE framework - an approach that defines story points as a measure of Complexity, Uncertainty, and Effort. This shared understanding ensures the entire team is on the same page about how work is being quantified.

Next, decide on the scale you'll use for estimation. Many teams stick with the standard Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 21...), but others prefer a modified version (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100). The modified scale simplifies higher estimates with rounder numbers, acknowledging that precision decreases as tasks grow in size. It's also helpful to set a threshold - commonly 13 or 21 - where items exceeding this value are split into smaller, more manageable chunks.

To improve consistency, create reference stories during a calibration session. For instance, a "1" might represent a small task like a text update, while a "5" could involve building an API endpoint. These examples act as anchors, allowing the team to compare new tasks against previously estimated ones using triangulation. Clear definitions and reference points help maintain steady velocity and improve the accuracy of your sprint planning.

Once your scale and baseline are in place, it's time to select tools that streamline the estimation process.

Choosing the Right Tools for Estimation

Picking the right tool can make estimation sessions more engaging and efficient. A critical feature to look for is simultaneous reveal, which ensures that estimates are shared at the same time. This avoids anchoring bias, where early estimates influence the rest of the team. As Abhay Talreja from TeachingAgile explains: in a recent iAmAgile blog post,

"The simultaneous reveal prevents early estimates from influencing others' thinking."

For distributed teams, digital tools are indispensable. iAmAgile is a great example, offering a Scrum poker tool tailored for collaborative estimation. It supports both standard and modified Fibonacci scales, integrates with Slack for seamless workflow management, and works on mobile devices, making it accessible from anywhere.

Additionally, look for tools that include special cards like "?" and "☕". A "?" card signals unclear requirements, while a "☕" card suggests a break or the need for more information. These features ensure estimates are thoughtful and not rushed when clarity is lacking.

With the right tools in place, the focus shifts to structuring an efficient and productive estimation session.

Setting Up a Productive Estimation Session

An efficient estimation session begins with a well-prepared backlog. The Product Owner should organize a prioritized list of tasks, ensuring each one has clear acceptance criteria. This preparation keeps discussions focused and minimizes time spent clarifying requirements.

During the session, pay attention to outlier estimates rather than averaging votes. For example, if one person assigns a "3" and another a "13", this gap highlights differing interpretations of the task. Discuss these differences, but keep each story's discussion brief - ideally between 2 and 5 minutes. If the team can't reach a consensus, default to the higher estimate to account for uncertainty or flag the task for further refinement.

To keep everyone aligned, create a Reference Story Poster. This visual guide lists the team's agreed-upon examples for each Fibonacci number, acting as a quick reference throughout the session. It helps ensure consistent calibration and a shared understanding of what the team is committing to deliver.

How To Estimate In Story Points?

Step-by-Step Guide to Using Fibonacci in Scrum

Step 1: Select a Backlog Item for Discussion

The session begins with the Product Owner introducing a single user story from the prioritized backlog. They explain what the story involves, why it’s important, and its acceptance criteria. At this stage, the team asks questions to clarify requirements, identify technical dependencies, and spot potential challenges. The focus here is on understanding the story, not estimating it just yet.

It’s important to keep the discussion on track. If the team veers into debates about design or implementation, steer the conversation back to building a shared understanding of the story. Once everyone is clear, the team moves on to selecting cards in the next step.

Step 2: Team Members Select Fibonacci Cards

Each team member privately selects a Fibonacci card that reflects their view of the story’s Complexity, Uncertainty, and Effort. This step is done independently, using either physical or digital cards, and without revealing choices to others. Keeping the selection private ensures unbiased input, which is a key part of agile practices.

If someone feels unsure about the story or believes more details are needed, they can choose the "?" card. This signals that additional clarification is required before proceeding.

Step 3: Reveal and Discuss Estimates

After everyone has chosen their cards, all estimates are revealed simultaneously. This is where planning poker shines. The team focuses on the outliers - those who picked significantly higher or lower numbers than the rest. For instance, if one person selects "3" and another selects "13", it’s a sign that their understanding of the story differs.

The person with the highest estimate explains their reasoning first, followed by the person with the lowest. These discussions help identify hidden complexities or misaligned perspectives. The goal isn’t to average the numbers but to uncover insights that bring the team closer to agreement.

Step 4: Reach Consensus or Refine the Item

The team re-votes after discussing the estimates. If most estimates fall within a single Fibonacci number, that number is assigned to the story. Typically, after two or three rounds, the team’s understanding aligns, and consensus is reached.

If the estimates remain far apart after a few minutes of discussion, go with the higher number to account for uncertainty. For stories estimated at "13" or higher, consider breaking them down into smaller, more manageable tasks.

Step 5: Repeat and Track Velocity

Repeat this process for the remaining backlog items. Over time, consistent estimation helps establish a predictable velocity. To measure this, sum up the story points completed for all items that meet the Definition of Done in a sprint. Use a rolling average from the last three to four sprints to create a stable baseline for planning future work.

Common Pitfalls and Best Practices

Having a clear process is only half the battle - avoiding common mistakes ensures estimation sessions run efficiently and effectively.

Avoiding Over-Precision on Small Numbers

Spending too much time debating whether a story is a 1 or a 2 can derail the session. These discussions often waste valuable time and undermine the purpose of using the Fibonacci sequence for estimation. To keep things moving, limit these debates to 2–5 minutes. If the team can’t agree, go with the higher estimate to account for any uncertainty.

It’s important to remember that story points reflect Complexity, Uncertainty, and Effort (CUE) rather than specific hours. If a story is estimated at 13 or higher, that’s a warning sign. Such a high estimate usually means the task is too complex or unclear to fit into a single sprint. Break it down into smaller, more manageable pieces instead.

Handling Experience Gaps and Bias

Beyond avoiding over-precision, teams need to address experience gaps and minimize bias during estimation. One effective method is using simultaneous reveal techniques. This involves team members selecting their estimates privately and revealing them all at once, which helps prevent anchoring bias .

When estimates differ significantly - like one person choosing a 2 while another picks an 8 - it’s a chance for valuable discussion. Ask the highest and lowest estimators to explain their reasoning. These conversations often uncover hidden risks or alternative approaches that might otherwise be missed. Additionally, ensure the Product Owner stays neutral during these sessions. Their role is to clarify requirements, not to steer the technical assessment.

Refining Estimates with Reference Stories

Without a shared baseline, a "5" can mean something entirely different to each team member. That’s why establishing reference stories is so important. For example, pick a completed 1-point story (like fixing a typo) and a completed 5-point story (such as implementing a small feature) to serve as benchmarks. When sizing new tasks, compare them directly to these reference stories to ensure consistency.

Retrospectives are an excellent time to fine-tune this process. Review 1–2 stories that were either significantly over- or under-estimated. This helps the team refine their understanding of the scale and improves the accuracy of future sprint planning. These steps build a stronger foundation for reliable and consistent estimations.

Conclusion

The Fibonacci sequence brings a fresh perspective to Scrum estimation by focusing on meaningful differences rather than false precision. Its non-linear gaps encourage teams to address the growing uncertainty of larger tasks, steering clear of trivial debates over minor details. This approach helps create more realistic and practical estimates.

But the true strength of Fibonacci lies in fostering collaboration. When one team member estimates a task as a 3 and another as a 13, it sparks essential discussions. These conversations often reveal hidden risks or uncover simpler solutions. As Mike Cohn, Founder of Mountain Goat Software, puts it:

"Numbers that are too close to one another are impossible to distinguish as estimates".

This collaborative process leads to a more predictable sprint velocity and better backlog management. Teams using Fibonacci often stabilize their velocity faster compared to those using linear scales or T-shirt sizing. High estimates, such as 13 or above, act as natural indicators that a story may need to be broken down, making the workload more manageable and improving sprint predictability. For many Agile teams, Why Fibonacci has become the go-to method for these reasons.

To maximize the benefits of Fibonacci-based estimation, teams should anchor their estimates with reference stories and use a consistent scale. Tools like iAmAgile can make estimation sessions even more efficient and engaging. With features like simultaneous disclosure to reduce bias, Slack integration for smooth planning, and customizable voting scales, it’s designed to keep the process seamless. Plus, its mobile-friendly interface ensures everyone can participate, whether they’re in the office or remote.

Stick to reference stories, avoid converting points to hours, and let Fibonacci guide your team toward accurate and collaborative estimates. By combining thoughtful preparation with a structured approach, Scrum teams can achieve steady, reliable outcomes, paving the way for a smoother workflow and greater confidence in tackling future tasks.

FAQs

How do we keep story points from turning into hours?

To keep story points from turning into a measure of time, use them to gauge relative effort or complexity, not hours. The Fibonacci sequence is a handy tool for comparing task sizes without tying them directly to time. Make sure your team understands this distinction and sticks to consistent estimation methods. Focus on velocity to monitor progress effectively. Linking story points to hours can lead to planning inaccuracies and create undue pressure on delivery timelines.

What should we do when estimates are far apart?

When team members come up with very different estimates during Scrum planning, it’s usually a sign that something’s unclear. Maybe the task’s scope isn’t well-defined, or some key details are missing. To address this, start by discussing the task as a group. This helps surface any misunderstandings, clarify the requirements, or bring up aspects that might have been overlooked.

If the estimates are still far apart after the discussion, it might be worth splitting the task into smaller, more manageable pieces. Alternatively, take another look at the task’s complexity to ensure everyone’s on the same page. Using the Fibonacci sequence for sizing tasks can also help. It shifts the focus to the relative effort and complexity of the work, encouraging a shared understanding and improving team alignment.

How can we create good reference stories for our scale?

To craft useful reference stories, focus on making them straightforward, specific, and reflective of typical work items. Start with small, easy-to-grasp examples that can serve as a baseline for estimating more extensive or complicated tasks. Using Fibonacci numbers is a handy way to compare effort levels, as the increasing gaps between numbers highlight areas of greater uncertainty. Make it a habit to revisit and refine your reference stories regularly. This keeps them accurate and ensures more consistent backlog estimations over time.