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.