Story points were originally developed as a metaphor to give a rough answer to the question of how much functionality could be delivered in a specific period of time. The problem is that all good metaphors are eventually abused or, worse, people forget that the metaphor is a simplification and approximation of real life. Metaphors become reality. Three basic behaviors of leaders and stakeholders in software development (broad definition) have lead the metaphor of story points to evolve into story points as measures — something they FAIL miserably at.
- Trying to answer when, how long and how much. Software costs money — lots and lots of money —and takes far more time to produce than most anyone outside the industry can understand. Every business wants to plan the introduction of products and features. If you want confirmation of this assertion, observe the frenetic activity firms have getting ready for the timeframe known as the Christmas shopping season. Failure to get to market with the right products at the right time and at the right prices is a life and death event for many companies. In public firms every product manager is asked to predict cost and revenue streams for their products. When software is required, they inevitably ask the dreaded “when, how long and how much” questions. The answers require predicting the future and then everyone is upset when they portray story points as a precise indicator of cost and duration.
- Measurement as a tool to manage. Management is often branded as an evil in some corners of agile. Managers are likened to Darth Vader keeping the clones in Star Wars in line. This perception is one of the reasons that there is substantial pressure to strip management down to its barest essential. Measurement becomes the Swiss army knife of management. Story points, because they are easy to collect, are collected and applied to evaluate the output of teams and individuals. Using story points as a measure to evaluate teams and individuals requires a shift in perceptions from a rough approximation to a measure that has accuracy and precision.
- Conflating numbers with precision. Numbers are precise. Story points were patterned after the famous Fibonacci Sequence in which the two previous numbers combine to create the next term in the sequence (eg. 1, 2, 3, 5 …). Note: Cohn’s numbers, another popular story point sequence adds some imprecision in the sequence to disrupt the false perception of precision as the numbers get larger. The precision of the story point creates a precision bias (a common cognitive bias) in which the person using story points conflates precision with accuracy (and vice versa). This leads to using story points in regression equations. The application of a number to the metaphor generates a perception accuracy that is not supported.
Story points are valuable as a tool to elicit discussion and to provide a rough approximation for how much work a team might deliver. They are not useful as a measure to support estimation or to manage or evaluate the capabilities and performance of team members. To be useful, measures must have both the accuracy and precision needed to make useful observations. We got to the point of confusing story points with measures because story points are useful. Because they are useful, experimentation has lead practitioners to try to use them for all sorts of things. However, when we forget they are no more than a rough approximation, we are going to fail more than succeed.