Question is why is schedule slippage and requirements not understood properly in software industry? Answer probably is wrong estimation. Usually estimates done at initial stage are approximate ballpark with level of information available.
Limited understanding of the requirements at initial stage results in a high margin of error in estimates. Cone of uncertainty describes estimates at the initial concept stage can vary 4x to the higher side or lower side. As we progress in project and start gaining more information estimates start converging into more accurate estimates.
So obvious question is how does Agile help flatten this cone? In Agile environments, we accept that software is jockeyed with uncertainty. Uncertainty decreases, as decisions are made around scope and approach are made, when we are certain about our understanding. This in turn helps us to be more accurate.
Agile Requirements are categorized in following in order of uncertainty:
• Agile Theme
• Agile Epic
• Agile User Story
• Agile Task
Large pieces of work(Theme, Epics, User Stories) are usually estimated in Fibonacci since at this stage assigning hours to complete them is unrealistic hence we focus on complexity. In other words we estimate small things(tasks) in hours, since it’s easy to measure in how much time can they be delivered.
So essentially, we have better and better understanding of the requirements as we move the stages from initial concept finally to testing and implementation thereby thinning the cone. In nutshell, as the project develops, we are in a better place to estimate more accurately.
To conclude, the agile model of working on smaller chunks and in shorter cycles allows the learning cycle for the entire project to be effective as its help to refine further scope as well as estimates on an ongoing basis.