A scrum point is an abstract unit of complexity of a user story. For developers, this concept usually takes a while to get accustomed to. Instead of estimating in development time, developers are asked to estimate a story’s complexity in terms of another reference story, which is commonly assigned 3 points.

This definition makes a point seem abstract since it does not have any unit of measure. For instance an estimate of 1 point does not mean the story will take 1 hour, 1 day or other conventional units of time.

At the beginning of each iteration, a team will sign up for a number of stories that are worth a certain number of points. The team also knows their time capacity, and a reasonable estimate of time spend on chores, bug fixes and other things not directly related to user stories.

Let’s say the total number of points we signed up for is P and the total time (capacity) we expect to spend directly on story development is T. Hence we can define p = T / P, where p is the time value of our abstract point!

Clearly, points are not abstract at all and are just obfuscated time value. We have been assigning time estimates to stories all along; we just did not know what it was exactly. Just think, our “abstract” point could have easily been one of these pretty numbers: 0.7098 days, 1.4142 days, 2.7182 days, etc.

I am not biased against fractional numbers, but I’d much rather use nicer numbers like 1 day or ½ day. In the end I am left wondering – why do we insist on confusing ourselves?

Fibonacci numbers is a numerical sequence in which each new term is the sum of the previous two. It starts like: 1, 1, 2, 3, 5, 8, 13 …. This sequence found a new use. Scrum practitioners started using it for estimating user stories under the premise that the larger the story the less precise is the estimate. Since the distance between Fibonacci numbers grows, it implicitly builds margin of error in.

I worked on several projects where we used Fibonacci numbers for story estimation and I disagree with the idea of using this sequence. I do not think it provides any benefit.

The first problem is apparent when you try to combine or breakdown a story. For example, let’s say we have an 8 point story A, which we realized can be broken down into two stories. Let’s say the break-off story B is estimated at 2 points, so what is the new A’?

Splitting a story should not change the total. In this example A’ should be 6 points (8 – 2). However, 6 is not a Fibonacci number and the closest numbers we can pick is 5 or 8. So, now we have to compromise. If 5 seems aggressive, then we should give A’ 8 points and then we end up with a total of 10. If we decide to risk underestimation and assign A’ 5 points, then our total goes down by 1 and is 7.

This does not feel right. After all, we view our applications as compositions of stories, but we cannot compose their complexity. Imagine if contractors only used Fibonacci numbers. Then, if you asked them to itemize their estimate you’d certainly get a much higher number because they would round individual estimates up to the nearest Fibonacci.

Mathematically, the problem here is that the arithmetic operations (+, -, …) are not closed over the set of Fibonacci numbers. That is to say the result of those operators would go outside the Fibonacci sequence.

Another problem is I cannot choose an estimate I believe is correct. A lot of times I wanted to assign 4 points to a story, but had to choose either 3 or 5. How does this help estimation accuracy? It doesn’t it builds in an estimation error.

If an estimation error grows proportional to the size of the task, then we can just express margin of error as a percentage of the estimate. This way we capture the fact that the larger the estimate the larger the margin of error without having to use only a subset of numbers for estimation.

In the end I believe we should use any numbers we want. We can use the actual results to judge our margin of error and calibrate future estimates.