One of my friends and Agile Coach - Yasub Hashmi once told me a great quote. I don’t remember whose quote it was but it goes like this -
Often people need to be reminded of what they already know.
Why is this quote important? Well, years on we have learned that the work we do is quite complex and often it is hard to make predictions about it. Yet, in my observations and personal experiences I have seen that customers/clients/stakeholders/management asks us to make many predictions about -
- When will X amount work be done?
- What can we get done in the next quarter or next 6 months?
- Can we tell how much it is going to cost?
- And so on.
I am not claiming here that these questions are irrelevant. For a business to be profitable and have sustainable growth, these and many such questions need to be answered. However, what we need to be reminded of, time and again, is in complex environments, at the very best, we can make forecasts but no predictions.
This is where the Cone of Uncertainty comes in to help.
Cone of Uncertainty
In traditional Project Management, the Cone of Uncertainty was used to highlight that as we make projections about the future, specially about the cost and effort, these projections will be inaccurate early on and are likely to become more accurate as we go through the various phases of the project.
The Cone of Uncertainty would be something similar to what is depicted in the following image.
However, the challenge with the above idea was, as we complete a particular phase we would have to assume that there won’t be any further changes from that particular phase. For ex: if we completed the Requirements Gathering phase, then no further changes would be allowed from the Requirements phase. That typically leads to the concept of “requirements freeze”.
What this often means is that as we keep completing various phases of project development, we will keep acquiring more and more certainty and thus our projections will become precise.
IMHO for the software world, this is a wrong notion. If requirements are frozen without even understanding whether the end user would be using it or not, then we are not really working for the benefit of the customer. We might end up building features that no one uses. A classic example that comes to my mind is the “Mail - Merge” feature in MS-Word. The last time I used that feature was in circa 2000 when I was attending a training on MS-Word. And in my knowledge I hardly know anyone who has used the “Mail-Merge” feature recently. I can be wrong here as I don’t have the actual usage statistics of that feature. Also, completing a particular phase in project development is no guarantee that we will acquire more certainty. Thus there is no guarantee that our projections are going to be any better.
So how does the Cone of Uncertainty even help?
Say hello to Scrum and the Cone of Uncertainty
Scrum, works on the principle of Empiricism i.e. keep Inspecting and Adapting with Transparency. In Scrum, we have Sprints and the only purpose to execute a Sprint is to get to a DONE Increment. There are no phases like requirements, analysis, architecture, code, build, test, release or others. There are only Sprints and each Sprint builds more understanding about the software being developed.
When we create an Increment every Sprint, it is hard evidence of the Scrum Team's ability to create a valuable product. It also enables new learning and better understanding of the overall system; thus making the team more effective. As the Scrum Team keeps completing work increments we can measure that work done within a Sprint and then use it to plot the cone of uncertainty.
Let me take an example. Say there is 500 units of work to be done and the Scrum Team makes a projection that they can complete 50 units of work every Sprint; which means all that work could be completed in 10 Sprints. However, before the first Sprint we do not have any evidence of what the team can complete actually and hence it is a forecast based on past experiences.
Now let’s say by the end of the first Sprint the Scrum Team is able to deliver only 10 units of work which means we are way away from our projections. In the second Sprint, the team again planned 50 units of work and this time they managed to deliver 40 units of work. Now if we draw trend lines using these two numbers then we would get an image as below:
This is what we term the “Cone of Uncertainty”. Now if someone asks for a projection what can we do in the third Sprint. We might be able to make a guess using this and say the team would deliver anywhere between 30 to 90 units of work. Or we can answer the question when 150 units of work would be done and that would be anywhere between 5 and 15 Sprints. Whoa! That’s a lot of variation and probably not acceptable.
But as we keep working on the product; learn more about it, the domain and build skills and expertise this variation will shrink. And over a period of time we will be in a position to make better forecasts.
For example, if after a few Sprints we are able to effectively churn out work with lesser variation then we can have a third trend line created as follows. Using this now we can answer similar questions but with more accuracy and acceptability. So, if we have to answer what can done by Sprint 8 or by when we can deliver 200 units of work then using the new trend line we can say by Sprint 8 we will be able to complete anywhere between 225 to 250 units of work or 200 units of work can be done anywhere between Sprint 6 and 7. Now this would be more acceptable.
With Scrum the idea is that, the Cone of Uncertainty is not based on phases of development but based on actual work completed and by putting empiricism in practice. This enables Scrum Teams to create more acceptable forecasts and do not surprise the stakeholders at the last minute.
In complex environments, one needs to remember that there is always variability as not all factors can be predefined. This often leads to having wrong estimates. Estimates if made only once, that too at the very beginning will be far from being accurate. Scrum Teams need to inspect and adapt continuously and keep updating their estimates regularly. “Cone of Uncertainty” could be a handy tool to raise transparency of estimates with everyone who is interested in them.
If you are interested to learn more about using empiricism then head to our website www.agilemania.com and make use of all the available resources.