In traditional Project Management, 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.
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.
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.
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.
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.
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.