The Tracker team recently pulled some data on team analytics cut by different pointing scales. Here are the headlines:

### Most teams use Linear scales…

### But, those who use Fibonacci scales tend to have better analytics

Let’s dig in a bit.

Looking only at currently active projects, 54% use Linear point scales, 38% use Fibonacci scales, and 8% use Powers of 2 scales. Of those, 90% of projects use Tracker’s default version of each scale; 10% have created a custom scale.

If we take only the projects using Tracker’s default Linear (0, 1, 2, 3) and default Fibonacci (0, 1, 2, 3, 5, 8), we see some interesting trends emerge. Unsurprisingly, both velocity and volatility are higher, on average, for projects using Fibonacci, as Fibonacci includes higher point values in its scale. To normalize for this, we divided volatility by velocity to get points-of-volatility per point-of-velocity (PoVol/PoVel).

With this normalization, we see that teams using the Linear scale averaged 6.6 PoVol/PoVel, while teams using the Fibonacci scale averaged only 4.6 PoVol/PoVel (a 30% decrease in volatility per point of velocity). This is a significant difference, as reduced volatility means improved predictive ability for the team and stakeholders.

But, why? What does a Fibonacci scale enable that a Linear scale doesn’t?

We have a few hypotheses. First, Fibonacci includes more point value options than Linear. This means teams can be more granular in their pointing discussions, and more precise in their pointing decisions. Teams’ alignment around what each different value means also increases over time, and with more values to choose from, that alignment can become even closer.

A second hypothesis is that, while complexity does not equal time, the reality is that more complex work often does take longer to complete. As complexity increases, the time to complete work will usually also increase, and that increase is not linear: 3-point stories often take longer to complete than three 1-point stories. For the highest-complexity stories, Fibonacci’s non-linear relative increases in point values better map to the amount of time it takes to complete complex work. Volatility measures changes in the average amount of complexity a team completes over a set amount of time (one iteration), so non-linear measurements of increased complexity could lead to fewer variations in the amount of complexity completed iteration to iteration.

A third, though less exciting, hypothesis is that Linear happens to be the default scale for all new Tracker projects. If a team is learning to use Tracker or unfamiliar with pointing and velocity, they would likely be using the default option for their pointing scale. A team actively choosing to switch to the Fibonacci scale likely correlates with their already having a higher level of alignment and maturity. As we noted earlier, more alignment equals less volatility, and scale choice may be a reflection, rather than a cause, of the better analytics for projects using Fibonacci.

So, should teams using Linear transition to Fibonacci? Maybe. There are pros and cons to each scale. Linear is simpler with fewer point value options, so for teams who are just forming or with folks who are unfamiliar with pointing and velocity, it may be easier to learn. For more mature and aligned teams, Fibonacci offers more granular pointing and potentially higher accuracy, as well as acknowledgement of the multiplying complexity of larger work.

Is there a concern that using Fibonacci could make for longer cycle times, as the highest value in that scale is more than double the highest value in Linear? Happily, no. We found that cycle times for the largest stories in each scale (3 in Linear and 8 in Fibonacci) had no significant difference in their cycle times (and in fact, 8-pointed stories had slightly lower cycle times by about 1%). This indicates that, as best practice supports, the size of the largest single piece of work a team is willing to do should remain constant, and lower volatility will come from greater accuracy in assigning points to work smaller than that. As always, we recommend breaking work into the smallest acceptable pieces to keep cycle times and reject rates low.

Does your team use a Linear or Fibonacci scale? How did you choose? Share your thoughts and experience in comments!