Relative Complexity Theory: how User Story estimations will auto-correct itself after x Sprints

As Agile coach I see a lot of teams struggling with giving estimations during the Sprint Planning Meeting. Is this struggling really needed? In the end, how good are we really in providing estimations? What happens with estimations in a iterative approach?

Because of all these questions, I started to do a small "research" on the idea behind estimations and the self-correcting aspect behind it. The result was really interesting and it does give me (and the team) a better feeling during the Sprint Planning Meeting, so enjoy!

What’s relative complexity?
Simply said, relative complexity is a way to measure a certain complexity relatively towards a certain baseline.

Why relative complexity estimation?
It’s something we all do in our daily life and apparently we human are pretty good in doing it.
We are "more accurate" to give a relative estimation instead of giving the exact time when it comes to finishing certain tasks. Especially when we apply Fibonacci numbers where we take uncertainties into consideration. 

• Example:  With jogging I know that it takes me approx. 40 mins to finish 5 KM. (yes, I'm not that fit apparently) Even though I've never jogged the 10 KM, I’m pretty sure it will take me at least 80+ mins (factor 2) to finish it. 

With this example I’m able to forecast a certain "time" by comparing my 5 KM walk with the 10 KM. Even though I've never actually done the 10 KM. (perhaps I should just do it and find out he?)

Estimation with your Scrum team:
The foundation of Scrum is based on the knowledge of the development team. They are the expert and therefore they can come up with a "better estimation" then anyone else. (at the end of the day, it’s still a guesstimate)

In Scrum the development team provides the Product Owner complexity estimations per User Story. Based on the given estimations, the development team is able to come up with some sort of an Agile Planning.

But does Relative Complexity Estimation really matters?
That's actually quite interesting… The characteristic of relative estimation in combination with iterations is that the given estimations will always correct itself, despite how wrong the team initially estimated.

The magic number regarding Project Management:
Every project has a couple of given characteristics:

• Every project eventually ends and therefore it has an end date.
• Problem: we don't know exactly when that is. We can try guessing, calculate etc., but we’ll never know the exact end date. (unless we have a magical crystal ball of course)
• Every project consists of team members and the team has a certain speed. (velocity)
• Problem: the speed is not fixed. It depends on a lot of factors such as vacation, focus, impediments, ad hoc operational issues etc.
• Because we work with Scrum, every item has a relative complexity with reference to the other items. The problem is that we don't know the exact relative complexity. We as a team can only guess it's relativity and even then it's never for sure.

The Research:

So taken all these into consideration I conducted my research which is: can User Story estimations auto-correct itself after x Sprints?

Let’s say we have that crystal ball and we know the 3 unknown that is mentioned above, so:

• We're doing project A with Scrum
• We've defined 15 User Stories and our crystal ball tells us the true relative complexity of the items.
• The crystal ball tells us that the team velocity per Sprint vary from 5 till 8 points. 
• Because we know the real relative complexity and the teams velocity, we can easily calculate the end date which is: 9 Sprints.

End date =  Σuser stories  / Velocity 
58 / (8+5)/2 = approx. 9 sprints.

figure 1: the reality

So now we’re in a Sprint Planning Meeting, the items are presented and the team is giving their relative complexity 

The team estimated the following:

As you can see, it’s totally different to the real (but unknown) complexity, but because it's unknown to us, we assume our estimation is true.

Because it's our first time measuring our velocity we'll just take a couple of items into the Sprint and see how we do. It we finish early we'll add more stories into the Sprint or we remove when it’s too much. The team as decided to start with the first 4 stories which has a total of 28 points.

The team finished all the Stories within the Sprint and state that their Team Velocity is 28 points, but in reality it was only 8 points. (1+2+3+2, see figure 1)
The Scrum Master sets up an initial planning and communicates that the project will finish within 61/ 28 = 3 Sprints.

So naturally the team pulls in 28 points of work in the next Sprint, not knowing they will NEVER finish it because in reality they aren’t taking 26 points, but 45 points worth of stories into the Sprint.

Eventually the team will only finish User Story 5 (1 point) because in reality that story was 8 points. So the Scrum Master adjust the planning and now it’s 61/ (28+1)/2 = 5 sprints.
I’m not going to lay out every scenario, but eventually when I finished the research, the team have finished all the Stories and the forecast was modified to 61/ 6.75 = approx. 10 Sprints.

To take my research to its extreme, I did the test again, but now I gave ALL the User Stories a complexity of 1. And surprise surprise the result was also +/- 9 Sprints.

Conclusion:

Despite what the team had initially estimated (so how close the team was to the truth or how wrong they were), the estimation will eventually automatically correct itself. So the conclusion would be:

During the Sprint Planning Meeting, it's not about trying to estimate the (unknown) exact points. It’s about having the discussion, come to a consensus and come up with a point. A point where the entire team is responsible for.
The goal should not be about guessing the points, but should be about agreeing on a specific point and strive for team commitment.

Of course the closer we can get towards the real estimations the faster we can come up with a planning, but again, that’s not the main goal. It can be a natural flow…