Story points: what it’s all about?

One of the most important aspects of the SCRUM is the so-called Story Points. This thing is oftenly combined with SCRUM-oriented team working flow. As an example of realization we can take a look at Planning Poker technique^[1].

The most common problem in the work of the SCRUM Team is the inability to correctly assess the complexity of the work and the time to be spent on its implementation. I would rather say that for many, it’s really hard to work out the right grading scale, and this requires experience or a specific approach. For the most effective and fast implementation of Story Points in the life of the team, you need to take already completed tasks from past projects and conduct a full analysis. This analysis should include the names of the tasks that were performed and their duration. Then everything is as simple as possible: you need to arrange these tasks in ascending order, sorting by time (thus you can’t expect that estimated time will meet real time needed for the task). Divide them into groups with the same or similar indicators and give ratings from your deck of SCRUM Poker cards.

Sooner or later, such an approach will surely make your team cool and progressive, which is the only right direction. A constantly modernizing team will always disperse its Velocity and delight its customers with success.

As story points express an effort to fulfill a story, the team must evaluate everything that will affect that effort. It could be:

• The amount of work to complete.
• The complexity of the work.
• Risks or uncertainties in work performance.

The amount of work to complete

The more work that needs to be done, the obviously more should be a conditional indicator of effort. We will use the development of two pages as an example. On the first page there should be only one field and the request to enter a name. On the second page the number of fields for the text should be 100.

The second page is not more complicated than the first one. It does not provide interaction with the fields, and they do not need to be filled out with anything but the text. Its development is not associated with any risks. The only difference between the two pages is that you need to do more work on the second one.

The second page should be assigned more story points. Maybe not 100 times more, although there are 100 times more fields on it. In the end, there are economies of scale, so in reality, we can spend only 2, 3, or 10 times more effort on the second page than on the first one.

The complexity of the work

You also need to consider complexity. Let's go back to our page with 100 fields, between which there are no interactions.

Now imagine another page with 100 fields. Some of them are fields with dates and calendar widgets. You can enter only a limited number of characters: for example, phone numbers. There are also fields where the checksum is checked (for example, with bank card numbers). In addition, there are interactions between fields. For a Visa card, the page should display a field with a three-digit CVV code, and for an American Express card, a four-digit field.

Although there are still 100 fields on the screen, the development will be more difficult, which means it will take longer. There is a high chance that the developer will make a mistake and he will have to roll back some of the changes and redo the work.

Risks or uncertainties in the performance of work

The assessment and risks or uncertain points in the work is important to include in consideration of the values of story points. For example, a team may need to evaluate the backlog element, about which the stakeholder cannot say anything specific. A similar situation: you need to give a margin of difficulty when introducing a feature that requires you to rewrite the old untrusted code without autotests.

Uncertainty as such is already reflected in the sequence of numbers for story points, which resembles the Fibonacci series: 1, 2, 3, 5, 8, 13, 20, 40, 100.

When the SCRUM Team is able to evaluate the work and it keeps a schedule of Velocity, sooner or later (or from the very beginning of the work) all the necessary scoring values will be transitioned in Story Points.

Proper assessment and use of Story Points really work their magic, because they connect the work of the whole team: the Development Team feels what it is capable of. SCRUM Master sees if the team has problems and what can be improved, and the Project Manager has no questions regarding how many and what kinds of tasks should be input in Backlog on the current Sprint.

1. One person is the leader, and he is not involved in the "game." The points that need to be evaluated are submitted for discussion in turn. Each item is allowed to discuss and review without estimates. After that, each team member selects a card and puts it face down. After everyone has put the cards - they are revealed. An ideal state is considered if there is practically no variation in values. As you might guess, this does not always happen. One way or another, the discarded cards will have the smallest and largest values. People who have thrown out such cards are given the floor, and they express their opinion about why the assessment was just like that. This allows the rest of the team to get more information and think about it, having heard the arguments, or to explain their point of view by throwing high or low positions. After this, the cards are discarded again and usually the gap is already narrowing, but if this does not happen, then the cycle repeats. In this case, it is recommended to introduce a timer for the cycle and put restrictions on the cycles, but in most cases, after the third time, the indicators become approximately the same. If there are slight discrepancies, then the priority indicator of the person who will directly be in the development of this task.