The meaning of Story Points

What are the Story Points?

The Story Points technique is one of the many tools we could use to estimate our work. It is more abstract than a classic hours-based approach to some extent, but the estimate is still an estimate, and it will deviate from the final cost as such.

We can define Story Points as an overall effort needed to deliver Product Backlog Item and its complexity.

During the planning, we take one item after another and assign some numbers to them. Usually, we use a modified Fibonacci sequence: 1, 2, 3, 5, 8, 13, 20, 40 and so on. One can use any numerical sequence. It is insignificant which number we use for an estimate as long as its relation to the value assigned to another Product Backlog Item makes sense. We need to compare them.

If a team decides to give 5 Story Points to a User Story, this story requires 2,5 times more effort than 2 Story Points item. There is nothing that prevents you from using other numbers or techniques. Mind that a 20 Story Points item is two times bigger than one with just 10.

It is all about the overall effort

Since we have to account for the overall effort needed to deliver a Product Backlog Item, there is much more to consider than just time spent on implementation. Many factors could impact the development, such as the amount of work, complexity, risks, uncertainty, missing information, and research needed.

At first, It may be hard to understand, so let us dive into the details. We need to give a User Story more points if it takes more time to complete it. A simple web form can be our example. Let's say we have a web form with 10 test fields. It is straightforward, but implementing it will be more time-consuming than if there were only two fields.

Mind the risk

It works the same considering risks related to Product Backlog Items. The threats have to reflect in the Story Points value. Stakeholders may push the Product Owner so they prepare a User Story lacking some information. This uncertainty increases overall risk and impacts the development process.

Working with a legacy code, without tests and any processes automation, should be consided too when assigning Story Points. Although, It may be nice to refactor the code and add some automation to the processes.

Don’t forget about the complexity

Complexity plays a crucial role in the process of estimating work with Story Points as well. Implementing ten text fields takes more time than two, but using various fields like date range pickers or multi-choice questions makes it even harder. Our form size stays the same, but there are other factors we need to think about.

Assigning one number to the User Story, regarding all the aspects we have mentioned so far, may seem intractable. The key is to stop thinking hours and focus on the effort needed. We need to answer a simple question. How much work is required to implement a Product Backlog Item with all those uncertainties and risks?

Moreover, mockups, automated tests, and infrastructure are usually in place. All of that should be considered in the Story Points assignment. First, doing so will be difficult, but ultimately, the team will gain traction. Not only will it make everything easier for them, but the management could benefit from the accuracy in the assessment of risks and complexity. It just has to be done the right way.

There are always antipatterns

There are a lot of Story Points antipatterns. Usually, teams want to switch to them after a series of failed hour estimates. Sometimes they do not even try to understand why they have failed or what the Story Points are for. Instead, they want to switch from one unit to a unitless number. It may lead to a few problems.

First of all, an estimate is and always will be an estimate. It is a prediction that may not and usually is not accurate. Moreover, if we estimate something can take us 20 hours and it takes 50, then we probably did not account for some factors. The same stuff can happen with User Stories. There are even more things to think about. It is harder to use them than hours.

Misusing Story Points may lead to some antipatterns.

One of the most popular ones is converting them to hours, which are easier to understand, especially by the managers, who are used to it. However, we have already mentioned that Story Points have more meaning behind them than just hours. They represent the overall effort needed to complete a Product Backlog Item, including time, risks, complexity, and uncertainty. If we convert two Story Points to four hours, we lose that uncertainty that was there at the beginning. Now we have 4 hours as a commitment. If it takes 5 hours, the managers are to point that out.

The last problem we will discuss is changing the estimate within a Sprint. There is a lot of uncertainty around us. The team has already started working on the Backlog Item, which had eight Story Points assigned, and as the work was progressing, the User Story turned out to be much more complex. Something natural, even intuitive, will be to change the estimate to thirteen. In such a situation, this value no longer has anything to do with the estimate or prediction. If the work is in progress, then "13" will refer to a large part of the work already done and can only be used to count Velocity. The estimate should be an estimate. However, if there was a situation where the task has gotten underestimated, it should be transparent, and the team should consider why this happened at the Retrospective. Maybe the User Story was imperfect, not very precise, or perhaps, it had no acceptance criteria. To be checked and discussed.

The meaning of Story Points

Story Points are great when we want to consider more than just the working hours alone. They allow for adding an overall effort needed to deliver Product Backlog Item to its estimate.

However, they are not as intuitive as they may initially seem. It takes a lot of practice to use them properly. Using them without understanding and context may cause frustration and disappointment. Be aware.