Story point estimation is widely used in agile software development.
With their numeric nature, story points are commonly summed up to determine the efforts that teams deliver in their sprints.
In this article, I am going to talk about why estimating sprint efforts with story points is a major misconception.
Please note that I am not using the term “sprint velocity" here intentionally. I think sprint velocity itself is a misconception, as it substitutes the velocity (direction and speed) with the speed alone. I have explained this in my article, “The Concept of Sprint Velocity Is Wrong!”
Does it take the same effort to build thirteen tricycles and one truck? Image author unknown.
What is a story point?
The common definition of a "story point" is “a unit of measure for expressing an estimate of the overall effort required to fully implement a product backlog item or any other piece of work.”
There is a very important aspect of a story point that is missed in this definition: a story point is a numeric unit of measure.
Why is the numeric nature of a story point its main downside?
As story points are numeric, it may feel natural that all the operations that can be done with numbers may be applied directly to story points.
But can we really apply arithmetic operations to story points? I don’t think so. With story points, 2+2 is not always 4.
The effort required to implement the product backlog item is not encapsulated in the item itself. There are many factors that complicate the development of the product backlog item.