New approaches to software development can sometimes seem at odds with the needs of business customers. For instance, ardent practitioners of the agile development methodology continue to advocate for rapid response approaches and the need for constant iteration to solve complex problems. On the other hand, companies and customers are demanding a strategic approach that provides insight into process, timing, and costs.
So, which of these yin and yang scenarios should developers employ? The answer is “both.”
Enter scope-based software estimation, which I maintain can be a powerful tool to ensure that projects remain on course and on budget. It is possible for schedule and budget estimation to be achieved without sacrificing any of the things that make agile development so potent.
Not everyone feels the same. Some would argue that there’s simply no place for estimates in an agile development world; that estimates cannot coexist with agile or “lean” methodologies like Scrum, which encourage teamwork, speed, and communication without constraints.
But scope-based software estimation can actually be very valuable, even to agile teams. Estimation can be used to identify potential risks right from the beginning, while giving both developers and executives a better perspective on project budgets and delivery timeframes -- enormously important factors to those cutting the checks. All of this can be done in conjunction with agile development processes.
The benefits are real and substantial. Let’s take a look at a few.
Scope-based estimation can help teams formulate an accurate schedule for product delivery.
The end goal of an agile development cycle is to create what’s known as a “Minimum Marketable Product” – the minimum value that a customer will accept in the product they have ordered. By implementing scope-based estimation planning at the very beginning of the development cycle, product owners and their teams can provide executives with a better picture of when they can expect delivery.
This timeframe doesn’t need to be set in stone. It can fluctuate and be adjusted based on the development process, and alternative scenarios can be explored up-front to meet a customer’s needs. But adopting this practice at the outset of a project can significantly increase that project’s chances of success, not to mention enhance the customer’s satisfaction levels.
Estimation supports annual budgeting.
All software or IT organizations are beholden to annual operating budgets. As such, businesses must prioritize software capabilities in order of need and organize them into deliverable projects. They must then determine the cost of those projects to see how many they can fit into those annual budgets.
Scope-based estimation can help customers and development teams determine which projects to prioritize given fiscal constraints. Ascertaining the scope of projects can provide a better idea of overall costs that could be incurred. Ideally this should be done early in the project life cycle, before any task planning takes place.
Estimation can help determine realistic demand to support capacity planning.
In addition to being limited by budgets, most IT organizations are also constrained by resources and have a relatively fixed short-term resource capacity that’s available. In short, there’s simply never enough help to go around, and developers are often pulled in different directions for various projects, making resource planning absolutely critical.
Scope-based estimation can help agile development teams figure out the capability demand that can be supported within their resource limitations. Again, this is not a static estimate; as priorities change, estimating techniques can easily be adjusted and updated to accommodate new demand portfolios and associated revenue needs. Scope, schedule and staffing levels can also be adjusted up or down to optimize demand and meet organizational needs as they evolve.
As you can see, estimation does not restrict agility. To the contrary – scope-based software estimation can flow and adjust right along with the agile methodology, yet provide a solid backbone for providing customers the information and insight they demand. It doesn’t inhibit agile, it enhances it, and should be a key part of any software development process.