Why Story Points are Superior to Effort Estimations

Story points are superior to effort estimations. Nevertheless, classic effort estimations are still part of day-to-day business in many companies. In agile companies, however, they have disappeared and have been replaced by complexity estimates with story points. This article shows why it makes sense to estimate story points and not effort.

Effort Estimations Promote Fear

Everyone knows classic effort estimates. Management requests the development organization to provide a forecast for the duration or the effort required to implement a requirement. This estimate then serves as the basis for the commercial evaluation of the requirement. If necessary, it is the basis for creating offers to customers. So far so good if the estimates mentioned are correct. But there are two catches.

On the one hand, traditional managers do not consider classic effort estimates as estimates. They are seen as a commitment to complete the task in question within the specified time. This leads to fear among developers that the estimate is too optimistic. As a result, the developers integrate buffers in their estimates. This in turn means that the processing time actually increases. Experience shows that if a developer has six hours for a task, he will also use it up. Regardless of whether his original estimate was four hours or not. Now many developers and managers are adding buffers along the evaluation chain for the estimation. This continues to inflate and, in the worst case, becomes uneconomical.

On the other hand, cost estimates are never correct, because nobody can estimate the duration of a task exactly. As a result, developers experience a negative sense of achievement with every estimate. The estimate given is damned wrong when it is created. This effect increases the further the implementation of a requirement lies in the future. It is almost impossible to make meaningful estimates for requirements that have not yet been discussed and refined in detail. The classic estimation methods leave no scope for risk assessment and the inclusion of uncertainties, ambiguities or potential stumbling blocks. Accordingly, they deviate massively from the later, actual processing time, especially for large problems.

Story Points Are Never Wrong

The inadequacies of classic effort estimation are countered in agile product development by using story points. Story points are a tool that reflects the complexity of requirements and not the implementation effort. Not only risks and imponderables are taken into account here. They also follow the cone of uncertainty, and thus provide an indication of the level of maturity of the assessed requirements.

The story points, and thus the levels of complexity, are not chosen or devised freely by the team. They result from the numbers in the Fibonacci sequence. These also depict natural growth functions in nature. This makes them well suited to assess the size of problems. Because people know these sizes intuitively from nature and their everyday life.

Fibonaccis Sequence as a Measure of Complexity

In Planning Poker, the numbers 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100 are commonly used to estimate complexity. As can be seen, the numbers from 20 upwards deviate from the Fibonacci sequence. However, this is irrelevant. The exponential growth of the sequence depicts the risks and growing uncertainty in the case of major problems.

It makes no difference whether a problem is 20 points or 21 points in size. In reality it could be 19 points. However, this is unclear, since the problem is still too big to be able to be sensibly surveyed. Accordingly, it must be broken down further and estimated again.

The velocity of a team is now not measured in terms of effort, but in completed story points. The only requirement is that a team estimates the story points in a consistent way. For this purpose, it can define reference problems of various orders of magnitude and use them again and again as a benchmark. The average speed of the last sprints is then used as an empirical basis for planning a sprint. This also makes it impossible to install buffers. If all requirements are consistently estimated and the planning is based on empirical data, there is no artificial buffer.

The good thing about estimating story points is that they are never wrong. This makes a big difference in terms of the emotional mood of a development team. Buffers and fear are also reduced, which also has an enormously positive impact on the work of the team.

The Financial Value of a Story Point

However, a question now arises. How can one make a financial evaluation of a requirement. Estimated expenses can be multiplied by an hourly rate and thus converted into a commercial statement. How can we get such a statement from the estimation with story points?

This question is easy to answer. Story points can of course be calculated back into actual expenses. However, this is done on the basis of empirical statements about the performance of the team. Let’s assume a team that has a speed of 50 story points in a 2 week sprint. Accordingly, this team delivers 100 points per month. So a story point in this team costs 1% of the monthly team costs. On this basis, each estimate can be converted into a financial assessment of the corresponding requirement.

One can now come up with the idea of ​​comparing different teams with one another and assessing them in terms of their cost efficiency with regard to a delivered story point. This is a bad, if not to say very, very, very bad idea. First, the size of a story point is not comparable between teams. Each team estimates differently and has different ideas about complexity. Secondly, agile methods are about increasing and optimizing the customer benefit and the value of the delivered product. However, no conclusions regarding customer value can be drawn from the cost of a story point.

Final Thoughts

In conclusion, it can be seen that the estimation of story points makes a lot more sense than the classic effort estimates. They take into account the risks and uncertainty of major problems. They do not demotivate through failure. Furthermore, it is not possible to add artificial buffers. Story points thus increase transparency in development. Therefore, story points are superior to effort estimations.