Scrum
Scrum vs. Waterfall or Effectiveness vs. Efficiency
Scrum vs. Waterfall – For all Scrum fans, let’s get the bad news out of the way: Scrum is just a compromise. The good news is that this is the only piece of bad news.
Menu
Yes, you have read correctly, this article is a world first.
What has not already been written about Story Points, the meaning, sense, benefit and procedure have been discussed controversially.
But one thing always remained untouched, everyone agreed that Story Points 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 Story Points via an algorithm.
With this Excel template you can easily calculate Story Points with just a few clicks.
All those who have already dealt intensively with Story Points and their methods of determination will certainly ask themselves how this is supposed to work at all, because at the moment of the Story Point 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 Story Point 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 Story Points in a scaled organisation with many teams, resistance often arises, backed up with all kinds of arguments. As Story Points are so far team-individual and subjective, they cannot be used by a scaled organisation for planning, forecasting and scenario simulations.
Even normalising Story Points (e.g. suggested by SAFe) does not change this as much as one would like.
The nature of Story Points is also often not understood and they are misinterpreted as a measure of effort.
Yet Story Points 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 Story Point estimate.
The fact that Story Points 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 Story Points 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 Story Points takes place.
Btw. to all critics of the comparability of teams:
Normalised Story Points 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 Story Points 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”.
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. 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 Story Points. 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 Story Points 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:
JOB SIZE = complexity + amount of work + uncertainty
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.
Complexity represents the number of elements and connections between them within a system
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.
With this Excel template you can easily calculate Story Points with just a few clicks.
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).
The Job Size calculator is directly integrated in the scagile project management app.
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:
Group 1
The first group are factors that take into account interdependence, relationships and interrelationships (interaction, the relationships between the elements of a system).
Group 2
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).
With this Excel template you can easily calculate Story Points with just a few clicks.
Scrum vs. Waterfall – For all Scrum fans, let’s get the bad news out of the way: Scrum is just a compromise. The good news is that this is the only piece of bad news.
How to precisely estimate the duration and costs of a project in Scrum – if understood as a risk management method.
Why we should not mix agile and classical project management – or why traffic lights are not helpful at roundabouts.
For scaled agile organizations it is frustrating when their project management tools don’t support their processes.
That’s why we developed scagile as an app which actively supports agile best-practices with features you haven’t even thought about and with which you’ll be able to create value flow across your entire organization.
