Using Fibonacci Story Points for Agile Estimation

Estimating the complexity and effort required to complete work is essential to agile software development. Utilizing a story point system based on the Fibonacci sequence can offer an effective means of estimating complexity.

What are Story Points?

Story points serve as a unit used to estimate the overall complexity and effort needed to fully implement a user story or feature within an agile framework like Scrum. They correlate with complexity, effort, and risk rather than time.

The Fibonacci Sequence

The Fibonacci sequence is a series of numbers where each number is the sum of the previous two, starting with 0 and 1. The first several numbers in the Fibonacci sequence are:

0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89...

Employing this sequence for story points offers a good scale of relative sizing while also accounting for uncertainty in estimation. The gaps between the numbers grow larger, reflecting greater uncertainty as complexity increases.

Estimating Complexity

In estimating with story points, the team discusses each user story and collectively assigns a story point value based on the relative complexity and effort involved. Some factors to consider:

• Complexity of problem
• Unknowns and risk
• Dependencies on other stories
• Writing Automated Tests
• QA

Estimating story points instead of time keeps the focus on the complexity of the work rather than when it will be completed. Considering both the level of complexity related to the unknown and the level of effort in terms of the tedium it would take to complete can generally provide a good understanding of the overall effort required to complete.

Since the Fibonacci sequence allows flexibility in work estimation, it always leaves room for unexpected work. Therefore, find the smallest work understood when pointing and assign it a 3 or a 5. While there may be a desire to point the smallest understood work smaller, like a 1 or a 2, there may be work in the future that is even smaller. Also, as the numbers get smaller, they have a smaller difference in measuring the complexity and effort required to complete it.

If a ticket is a 1, is a 2 twice as large? What is the delta between a 1 and a 2? What about a 2 and a 3? Is 3 one and a half times as much effort? Again, the delta between numbers this low doesn’t provide enough understanding of the distinction between the work. Also, because the delta is smaller, there's an increased expectation that tickets sized at a 1 or a 2 should be identical levels of effort. A ticket sized a 3 and a 5 have a larger delta around them, which provides more flexibility in how much effort two tickets pointed at a 5 have.

For instance, a 5 has to be less than an 8 and greater than a 3. It may be similar to another 5, but it doesn't have to be exact. Because the goal of a story point is to measure complexity, there should be an element of the unknown in that estimation.

Pointing the smallest at 3 leaves room for a 1, which is three times less effort. Starting at a 1 could quickly lead to pointing out something as simple as fixing copy on a website, like adding punctuation or creating an email sign-up form. Both are considered low effort and low complexity, but one is significantly less than the other.

If all tickets are being pointed at a 1, 2, or 3, there is no real complexity in the work, and the work is more likely complicated and not complex. Perhaps the work is complicated but well understood and known, and there are preferred practices on how to solve that work. In that case, a Lean methodology would better manage the work.

Part of the benefit of using an iterative agile development cycle, like XP or SCRUM, is that it provides extremely short feedback loops for validating work. This is usually needed when the problems being solved are novel and the solutions being created are emergent. If not, Kanban and Lean may be a better fit for managing the 1, 2, or 3 tickets.

However, if the work involves complexity and requires experimentation and discovery, the smallest ticket sizes are probably better represented with a 3 or 5. These numbers provide a better relative sense of the level of effort required.

Benefits of Story Points

Here are some benefits of using story points over time estimation:

• Abstract from time - Story points measure complexity, not the time it will take. This removes the tendency to pad estimates to be safe.
• Promote discussion - Assigning story points leads to a greater discussion of scope, unknowns, and effort needed. The focus stays on the complexity of the work.
• Avoid false precision - Time estimates try to predict an exact number of hours/days despite inherent uncertainty. Story points use a scale like Fibonacci to show the ambiguity.
• Separate estimation from commitment - With time estimates, if a task goes over the estimated time, it is seen as "late." Story points estimate complexity, while the team commits to a number of points per sprint.
• Velocity metric - Velocity tracked in story points shows how much complexity a team can handle per sprint. This aids in planning and estimating future work.
• Uncouple from individuals - Story points measure the complexity of the problem rather than a person's specific skill/speed.
• Allow for variation - Story Points account for higher degrees of uncertainty as the numbers get larger, but they also provide a larger delta between the numbers around them. This means that when two similar tickets are sized an 8, they don’t necessarily have to be equal. They’re more complex than a 5 but less than a 13. This provides a mathematical buffer when calculating a team's velocity.

As a rule of thumb, when a story point is greater than 13, it’s a strong indicator that the work isn’t well defined and the level of uncertainty is too high. Seeing story points of this size indicates that the story needs to be split. When splitting, the values don’t always have to be summed to equal the original estimate. One benefit of splitting stories is that it becomes possible to be more specific about what should be done as part of that story. For instance, splitting a 13 in two may yield a 5 and an 8, or two 8s, or even two 5s. Remember, the individual stories should again be pointed in relation to other stories of similar size.

Story Points Aid with Prioritization

Once all the stories are pointed and split, evaluating which stories will likely put the sprint at risk becomes easier. Determining which stories are required to achieve the sprint goal is also easier.

Size Tasks Relatively

User stories and backlog items should be pointed relative to each other based on complexity. If the team has completed a task of similar complexity to a new task being pointed, use that history as a reference point. This doesn't mean things can't shift as the team gets more comfortable pointing, but historical context can help.

Understand Workload

When planning a sprint, the team can sum story points for tasks to understand the workload and ensure they aren't overcommitting. Knowing a team's velocity and adjusted velocity helps ensure the team isn't overcommitting. Typically, a team should plan up to their adjusted velocity so there is a buffer left for unplanned work. Knowing how many points each sprint a team spends on unplanned work can help the team better estimate and plan for future distractions and interruptions.

Balance Workload

The team can look at story point totals by discipline and balance workloads. If you have a cross-functional team of front end and back end, you can identify how the point distribution is between those two disciplines. If you plan up to your adjusted velocity but all the work is focused on the front end and none on the backend, it's probably a good indicator the team won't complete the sprint. This can also indicate a need for cross-training, building full-stack developers, or re-assessing hiring needs. Depending on the number of teams, this may also indicate a need for a change in team composition and re-assigning individuals to other teams where they can provide more value.

Velocity Tracking

Velocity, or the rate of story point completion per sprint, guides future sprint planning and prioritization. As mentioned above, it's important to identify the completed points spent on value-added activities and non-value-added activities like re-work. Measuring the points spent on non-value-added activities will give the team a buffer. Subtracting that from the total velocity will give the team their adjusted velocity and a good limit for sprint planning. This may fluctuate quite in the first few sprints as the team gets comfortable with story-pointing, but it should average out fairly quickly.

Identify Process Issues

If story points completed constantly differ from those planned, it could indicate an issue with estimation or planning. It's important to point out everything, not just user stories. One advantage of story points is that it creates a way to measure the capacity and throughput of a team. A team can determine how much effort they spend on bugs and rework by pointing out everything.

Examining story point sizes helps guide where to focus effort, how to balance workloads, and how to prioritize and sequence work. Story points add important context to the relative complexity of work for teams.

Here are some tips to help estimate story points accurately for tasks of varying complexity:

• Frame a reference story - Estimate a simple story as 3 or 5 points to set a baseline. Use it as a reference to size other stories.
• Consider all aspects - Factor in front-end, backend, testing, documentation, etc. A story may be more complex than it first appears.
• Estimate by comparison - Estimate new stories relative to others already given points rather than in isolation.
• Re-estimate when needed - If a story turns out more complex than initially thought, re-estimate it with the new information. Use this information to re-evaluate the success of the sprint.
• Track velocity - Look at the team's velocity (points per sprint) to improve estimating and know how much work can be done.
• Break large stories down - If a story is too complex to estimate, break it into smaller "bite-sized" stories to estimate individually.
• Avoid false precision - Use the Fibonacci sequence scale (1, 2, 3, 5, 8, 13) rather than sequential numbers to account for uncertainty.
• Estimate conservatively - When uncertain, round the story points up. It is better to estimate high than low, as low estimates can increase the risk of not completing sprints. Remember to constantly re-point stories if learning indicates the story is smaller or larger than initially estimated. At any point, pulling more work into a sprint is possible. Removing work is also possible but requires another mini-sprint planning session to identify what items to remove.
• Improve over time - Estimating is a learned skill. Accuracy will improve with practice across sprints.

Accurate story point estimation requires experience and collaboration. Allow time for the team to improve estimation skills together. The goal is to reflect relative complexity, not to predict the exact time needed.

Once a team can point stories consistently using the Fibonacci sequence, they can plan their sprints more accurately, have less need to work overtime, and be happier overall.

This also unlocks future capabilities such as:

• The ability to do large effort estimations, where a team can now estimate an entire project or initiative.
• Identify how much effort is spent on waste in the system.
• Calculate an accurate “buffer” and have an adjusted velocity that captures the amount of value-added work completed each sprint.
• Identify process improvement opportunities by focusing on reducing the amount of unplanned work in the system.