It’s a story we hear a lot in the software business these days, especially with agile development. New functionality is needed within a certain amount of time and within a certain budget.
Some might say, "no problem! We can figure it out as we go along." They might feel comfortable because each sprint has already been set in stone. But there are business-related questions that need to be answered before sprint-level planning takes place and before we commit to goals that might not be achievable at the release and portfolio levels. Should we agree to do this project? Can we really get all of the work done within our constraints? Will the software be reliable at delivery? How does this project impact our annual and multi-year forecasts?
This is where having reliable big picture numbers can be helpful. Wouldn’t it be great if senior management and the technical team were on the same page early? There are empirically-based estimation tools that can help. The naysayers might say that the technical requirements aren’t firm enough to come up with early estimates before the sprint planning takes place. But the fact is that some of these models (the good ones) allow for managing uncertainty and they do it based on historical data. The slide below shows a summary example of a release-level estimate for cost, duration, and reliability.
Estimating early also allows for cost and resource optimization and risk mitigation at the enterprise level. Senior management can see how each release impacts their portfolio when generating annual and multi-year budgets. This type of analysis brings to the forefront which projects are at risk and which ones allow for opportunities to save money.
Estimates can be a barometer of things to come. They can provide alternatives that can be negotiated by decision makers and they can provide a communication vehicle between the project stakeholders and senior managers. This can all be done before sprint level planning takes place; saving big time, big money, and big frustration.