Calculate Story Points instead of estimating them

Yes, you have read correctly, this article is a world first. What has not already been written about StoryPoints, the meaning, sense, benefit and procedure have been discussed controversially. But one thing always remained untouched, everyone agreed that StoryPoints are only appreciated individually. That will change today. With this article we add a qualitatively absolutely new aspect to the whole discussion, the calculation of StoryPoints via an algorithm. 

Story Points Calculator | scagile Blog

Get your free Story Point Calculator

Download the free Story Point Calculator in the Excel template with instructions included.

All those who have already dealt intensively with StoryPoints and their methods of determination will certainly ask themselves how this is supposed to work at all, because at the moment of the StoryPoint estimation, there is hardly any data about a story or an epic to which one could apply an algorithm. And of course, we are moving in an agile environment, which means that the techniques and methods we introduce must not be very complicated or elaborate. To be fair, we will not be able to do without estimation to determine the data for the calculation algorithm, and there are also some limitations in applicability. But in the vast majority of software development projects, the calculation works amazingly well and delivers very valid data.  

We also need to talk about the added value for the teams and for the organisation of such a calculation, because without a clearly recognisable added value, new procedures should not be introduced at all. This was one of the problems that was often encountered in classic project management, that everything possible was measured for purely statistical reasons and with the corresponding effort, without any significant added value for the team or project organisation being recognisable at all.  

So what added value would a StoryPoint calculation method have? Let’s start with this as an introduction to the description of the method itself. If after this section you are not convinced of the added value of such a method, then save some time and do not need to read any further.  

StoryPoints have always caused problems, which is why they are so controversially discussed in the communities and within many organisations. Especially when an “agile coach” wants to introduce StoryPoints in a scaled organisation with many teams, resistance often arises, backed up with all kinds of arguments. As StoryPoints are so far team-individual and subjective, they cannot be used by a scaled organisation for planning, forecasting and scenario simulations. Even normalising StoryPoints (e.g. suggested by SAFe) does not change this as much as one would like. The nature of StoryPoints is also often not understood and they are misinterpreted as a measure of effort. Yet StoryPoints are merely a measure of complexity, but who can provide a good definition of the term “complexity”. And that would also have to apply throughout the organisation, and with such a definition we slide into the philosophical anyway. And while we’re on the subject of philosophy, we’re a bit like the philosophers and all the sciences that search for truth when it comes to complexity: We presuppose what we actually want to prove, namely that truth exists at all. In our case, we don’t know exactly how we define complexity, but we do define it. And we do so by means of an individual and subjective estimate. It doesn’t sound like an exact science, and at this point I can understand the critics of the StoryPoint estimate.  

The fact that StoryPoints still exist at all in the critique is simply because they are very important for the agile process. There is not much in the agile process that looks like a number and that we can use to create at least a rudimentary planning and controlling basis, i.e. to measure velocity and get a feeling about whether the agile process is (still) running well or when my MVP can possibly be released. Even for prioritising tasks according to e.g. WSJF (weighted shortest job first), I have to determine the scope of the task (job size) somehow.  

In order not to drag out this argument here, I have summarised everything around the definition and meaning of StoryPoints in this article: 

The point here is not to justify why StoryPoints are important, but what added value their calculation has compared to an individual (made by individuals) and subjective (according to their personal perception) estimate.  

A calculation per se has the property of being objective – that is, factual and neutral. Neutrality is of great importance in a scaled environment, because the values can be used across teams and nothing stands in the way of organisation-wide use, i.e. a normalisation of the StoryPoints takes place. Btw. to all critics of the comparability of teams: normalised StoryPoints do not make the teams comparable, but only their tasks. Objectivity, in turn, ensures that neutrality is not just feigned – as with the normalisation proposed by SAFe, which is no longer individual but still subjective – but remains consistent (consistent, sustainable) and comprehensible. So we can also describe objective here as “sustainable” and “independent”. In sum, a procedure for calculating StoryPoints provides the organisation with an equally sustainable and independent assessment of its tasks. I think it is very obvious and you don’t have to have studied economics to realise what an organisation can do with sustainably and independently assessed tasks in terms of planning, commitment, forecasting ability and controlling. No, it does not mutate into a classic organisation again, but it does exactly what SAFe (5.1) formulates in Principle #1 “take an economic view”. 

And what do the teams get out of it? First of all – and we will see this in more detail later when describing the process – the team gets much more clarity about the task to be accomplished (the story, the feature, the epic) not only through the calculated value per se, but above all through the process and the way the team is actively involved in the process. This facilitates – and I assume shortens – in many cases the planning process for the coming iteration (sprint, PI).  

Teams also often find it difficult to explain and sometimes even justify the complexity of their tasks to stakeholders. They would basically be freed from this burden and can concentrate entirely on solving the task.   

Of course, computation also reduces the likelihood of error and helps to better support two of the key agile values that teams consistently struggle with: Flow and Commitment. The former pays into the KPI “Velocity”, while the latter is represented by the KPI “Sprint Accuracy”, two of the most important KPI’s for the performance of teams or Development Valuestreams (SAFe).  

So, now to the procedure itself. And here I hand over to my co-author Gergana Petrova, who was instrumental in developing this procedure and ensured that this calculation method became part of our product scagile.app. There you can test the method live.  

The procedure is used by agile teams in the iteration planning phase, such as sprint planning (Scrum), PI or stage planning (e.g. SAFe), or also preparations for this (refinements, pre-plannings). The method can thus be applied at story level as well as at feature or epic level. The crucial point is that the calculation is still based on data collected by the team. Despite the objectivity of the calculation, the result remains the responsibility of the team.  

Since agile events are as short as possible, but especially timeboxed, the process should also not take much time and be able to be used without administrative effort, so it must be fast, simple and intuitive.  

The result of the calculation is the number of StoryPoints. These represent the “job size”, i.e. the size of the task. It is important to mention this again and again, because it is often misunderstood. The StoryPoints do not represent the effort, but the job-size, because effort is a property of the team, while job-size is a property of the task. The job-size is made up of the complexity plus the scope of the task, so the following formula applies

A third parameter, “uncertainty”, is added to the two parameters. This is always set if the task still contains risks regarding a possible scope change (e.g. “If it turns out that the interface is not performant enough, we have to change the data”). “Uncertainty” does not mean whether the task is clear to the team (“we know what to do, but not how, because we have never done this before”), because that would again be a property of the team and only comes into play in the effort estimation, not in the job-size.  

Unfortunately, the term complexity also causes problems again and again, as there is no such clear and/or immediately obvious definition for it that can be transferred to us here. As we will see in a moment, however, that does not matter. Let us just say here that we refer to two definitions of the term that we find very appropriate.  

  1. Complexity represents the number of elements and connections between them within a system 
  1. Complexity represents the information content of data 

A sufficient critique of these two definitions would definitely go beyond the scope of this article and also beyond the scope of an entire book. In designing the algorithm, we have been “inspired” – let’s call it – quite roughly by these two definitions.  

To determine the job size of a backlog item (story, feature, epic), we ask 8 (version 1) to 10 (version 2) questions that are answered by the team. To make it quick – as described above – there are only these 8 to 10 questions. You could ask a lot more questions and you would probably get even more accurate results. But for us it is more important that the procedure remains fast, simple and practicable, because it should be used in every iteration.  

In addition, most teams use the (adjusted) Fibonacci sequence and thus the values (0,1,2,3,5,8,13,20,40,100). Thus, only one of the 10 values is to be determined via the algorithm. The requirement for the algorithm is therefore not so much maximum precision as maximum consistency.  

Each of the 8 to 10 questions is rated by the team in only three expressions (none, little, much or low, medium, high). Our empirical tests have shown that the best balance between speed of estimation, accuracy and consistency is achieved with only three values. Thus, a backlog item with an implementation effort of several days (story) to several weeks (feature or epic) can be assessed with the procedure within 1 to 2 minutes. This is a perfectly acceptable time investment.  

The 8 to 10 factors are weighted among each other. We have determined the selection of factors to be evaluated and their weighting among each other in countless tests with a large number of teams of developers and architects. The factors and their weighting refer to average software development projects. It is very likely that not all projects or project types can be represented with exactly these factors. Here, the questions and weightings could be adjusted accordingly. In the meantime, we have even been able to successfully evaluate marketing projects with an adapted set of questions.   

Now to the factors themselves. Based on the two definitions of complexity above, the factors we have defined can be divided mentally into two groups. The first group are factors that take into account interdependence, relationships and interrelationships (interaction, the relationships between the elements of a system). The factors in this group are: 

The second group describes the nature of the elements themselves. Here again we have 4 dimensions: 

As described above, each factor is given a value (low, medium, high) and has a weighting in the overall algorithm, which then calculates the StoryPoints.  

As complicated as the whole process sounds, its application is simple and fast. In addition to a sustainable and independent result, the advantage of its application lies particularly in the fact that teams gain much more clarity about the subject matter when answering the questions and recognise risks at an early stage. This alone leads to more reliable planning (team) and forecasting ability (organisation). 

Story Points Calculator | scagile Blog

Get your free Story Point Calculator

Download the free Story Point Calculator in the Excel template with instructions included.

Author:
Als agile Coach begleitete Klaus Riedel mit seinem Team die digitale Transformation und die Einführung von Scrum und SAFe in großen Organisationen wie Deutsche Bank, Conrad Electronics, Volkswagen, PWC und anderen. In der Blubito Agile Academy bildet er Nachwuchs Agile Experts aus. Alle seine gewonnenen praktischen Erfahrungen über mehr als 10 Jahre agile Transformation sind in die Artikel seines Blogs eingeflossen. Darüber hinaus berät er Unternehmen bei der Umsetzung von Off- und Nearshore- Strategien, sowie bei der Einführung agiler Entwicklungs-Methodologien und neuer Technologien. Seit 2016 unterrichtet er zudem agiles Projektmanagement an der deutschen Fakultät der TU Sofia.

Leave a Reply

Your email address will not be published. Required fields are marked *

Dein kostenloses WSJF Excel Template + Schritt-für-Schritt Anleitung
Wir senden dir dein kostenloses Excel Template zur einfachen Priorisierung eures Backlogs inklusive einer Anleitung per Email zu. Bitte hinterlasse uns dafür deine Kontaktdaten.
Dein kostenloses WSJF Excel Template + Schritt-für-Schritt Anleitung
Wir senden dir dein kostenloses Excel Template zur einfachen Priorisierung eures Backlogs inklusive einer Anleitung per Email zu. Bitte hinterlasse uns dafür deine Kontaktdaten.
Your free WSJF Excel Template + step-by-step guide
We'll send you the free Excel Template to easily prioritize your backlog inclusive a guide via email. Please enter here your contact data.
Your free WSJF Excel Template + step-by-step guide
We'll send you the free Excel Template to easily prioritize your backlog inclusive a guide via email. Please enter here your contact data.
Dein kostenloser Complexity Calculator + Schritt-für-Schritt Anleitung
Wir senden dir dein kostenloses Excel Template zur einfachen Berechnung der omplexität in Story Points inklusive einer Anleitung per Email zu. Bitte hinterlasse uns dafür deine Kontaktdaten.
Dein kostenloses Complexity Calculator + Schritt-für-Schritt Anleitung
Wir senden dir dein kostenloses Excel Template zur einfachen Berechnung der Komplexität in Story Points inklusive einer Anleitung per Email zu. Bitte hinterlasse uns dafür deine Kontaktdaten.
Your free Complexity Calculator + Step-by-step user guide
We'll send you the free Excel Template to easily prioritize your backlog inclusive a guide via email. Please enter here your contact data.
Your free Complexity Calculator + Step-by-step user guide
We'll send you the free Excel Template to easily prioritize your backlog inclusive a guide via email. Please enter here your contact data.
Your free Velocity Template + Step-by-step user guide
We'll send you the free Excel Template to easily prioritize your backlog inclusive a guide via email. Please enter here your contact data.
Your free Velocity Template + Step-by-step user guide
We'll send you the free Excel Template to easily prioritize your backlog inclusive a guide via email. Please enter here your contact data.

Dein kostenloser Velocity Template + Schritt-für-Schritt Anleitung

Wir senden dir dein kostenloses Excel Template zur einfachen Berechnung der complexität in Story Points inklusive einer Anleitung per Email zu. Bitte hinterlasse uns dafür deine Kontaktdaten.
Dein kostenloser Velocity Template + Schritt-für-Schritt Anleitung
Wir senden dir dein kostenloses Excel Template zur einfachen Berechnung der omplexität in Story Points inklusive einer Anleitung per Email zu. Bitte hinterlasse uns dafür deine Kontaktdaten.