Estimating involves predicting accurately the amount of effort needed to implement a software engineering development. This includes the effort, cost once the required resources are known, and the schedule which includes the sequencing of requirements.
Challenges in software estimation
Predicting software development costs has been challenging since the beginning of time. Furthermore, many of the challenges that we still find today, have been described in 1975 in the seminal book The mythical man-month by Frederick Brooks, Jr. [1]
First, our techniques of estimating are poorly developed. More seriously, they reflect an unvoiced assumption which is quite un- true, i.e., that all will go well.
Second, our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable.
Third, because we are uncertain of our estimates, software managers often lack the courteous stubbornness of Antoine’s chef.
Fourth, schedule progress is poorly monitored. Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering.
Fifth, when schedule slippage is recognized, the natural (and traditional) response is to add manpower. Like dousing a fire with gasoline, this makes matters worse, much worse. More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster.
The mythical man-month by Frederick Brooks, Jr.
The cone of uncertainty
The other important concept is the cone of uncertainty which states that the closer we get to the software being operational, the greater the certainty. Conversely, the further away from release day, the more uncertainty it will be experienced. It was first coined by Steve McConnell’s book Software Project Survival Guide in 1997 [2].
According to the diagram above, the cone displays highest level of uncertainty in early stages of the development lifecycle. In these early stages, variability might range from 4x to 0.25x. This means that if a project is estimated to take a month, it could actually end up taking from 1 week to 4 months.
As we progress through the different phases, we gain higher and higher certainty. In an agile methodology this would be evident every sprint. And having a lot of feedback in every sprint will quickly increase the certainty of what we want to deliver.
Software estimation techniques across development phases
During a feasibility study or early initiation phase
- Using historical data from previous projects to apply analogy-based estimation such as ANGEL, Weighted Micro Function Points
- Estimates by experienced team members
- Group sessions to get estimates
- Using pre-defined algorithms or parametric models which allows to input number of interfaces with external parties, modules, screens, etc. and get an estimate on the overall effort
During requirement gathering phase
- All techniques mentioned in the initiation phase will also work in this phase
- Requirement decomposition, unit estimation and aggregation
During detailed design phase or Sprint planning
In this phase we will be getting a lot more certainty on what needs to be built, so we start shifting to a more detail approach:
- Breaking down into tasks or decomposing requirements/features and estimating in separate units and then aggregating estimates
- Counting number of interfaces, modules, screens, etc. and get an estimate on the overall effort by multiplying by a pre-defined effort
- Estimates by experienced Senior developers
- Group estimates techniques like T-Shirt sizing, Planning poker, affinity grouping and Wideband Delphi
During building time or Sprint planning
- Using historical data from previous iterations in the same project
- Estimates by experienced Senior developers or the developer that will implement the feature
- Bottom-up / task level estimation
- Counting and calculating effort could still be useful if there is enough fine-grained data on previous iterations
