Techniques used to estimate the delivery cost (in man hours) of a software project can be split into two broad groups, algorithmic techniques and non-algorithmic techniques.
Algorithmic Techniques
Traditional algorithmic estimation techniques were developed in the 1970s and 80s and widely employed in large software projects. They involved formulaic calculations based upon the size of the code required to complete the project, or the number and complexity of features to be included in the project. Two of the more widely-used techniques are briefly discussed here, and a Python implementation of the formulae that I wrote can be found here.
COCOMO (constructive cost model) is a formerly widely used technique developed by Barry Boehm in the late 1970s. It is based upon the size of the project in lines of code, to which an algorithm is applied in order to calculate the number of man-months required to complete the proposed project. The parameters of the algorithm include a measurement of the experience of the development team, the type of hardware being used and the complexity of the project requirements.
Function Points is another estimation technique designed in the late 1970s. Rather than counting lines of code, calculations are made using the number of screens, reports, queries, files, database tables and objects. Like the COCOMO technique, the function points calculations use historical data for some of the parameters. The calculation is more complex and involved than the COCOMO formula, and results were deemed to be more accurate, though a correlation was found between the number of lines of code and the number of function points, questioning the validity of this technique.
My thoughts
It is extremely difficult to effectively apply traditional algorithmic cost estimation methods to agile software development as both of the above techniques require a full and detailed planning of the scope of the project, while agile methodologies are based on multiple iterations of refining changing requirements followed by sprints of software development.
Non-Algorithmic Techniques
There are a number of non-algorithmic estimation techniques which make use of the expertise of the team members and their previous experience.These can be broadly termed ‘expert judgement’ techniques. Some, like Wideband Delphi rely on the input of the entire team, developers, product managers, content creators and others. Each is asked to estimate the development cost of a function or feature of the application, and discussions take place until a broad consensus is reached. There have been some attempts to formalise this process including the under the banner of Planning Poker.
Other expert judgement techniques involve estimations agreed upon by a selected group of ‘experts’. This kind of estimation is more widely used these days as they are considered more flexible and do not require the detailed plan of the waterfall software development lifecycle.
Chosen Method of Estimation
We thought it was obvious that the historically-used algorithmic techniques were obsolete and so decided to make use of one of the ‘expert judgement’ methods. The issue with this approach was that only two members of our team had previously worked on a professional software project, so we were distinctly lacking in expertise. This led to our initial estimations at the project's inception effectively being nothing more that uninformed guesses.
However, for the final assignment we had to predict the future development cost for the remaining stories and epics. At this stage, we had completed after two development sprints, giving us some historical data to base our estimations upon. We also narrowed our group of ‘experts’ to only include the Project Manager and the two members of the development team who had worked on the codebase. We believe that by being selective in the estimators, our estimations were likely to be more accurate. This estimation process was carried out in an informal meeting, rather than following the structure of planning poker. Next time, if I were to do this again, I'd like to try follow the more structured approach of planning poker to evaluate whether using it is advantageous or not. Being complete amateurs in project estimations, it would probably be helpful to have a structure to follow to ensure we were getting a proper consensus.
On a personal level, I was wondering how project estimation is done at my work. I mean, I know that our development team estimates upcoming work by discussing its complexity and comparing it to previously completed work. We then discuss any potential risks to the timeframe, such as upcoming annual leave, reliance on outside parties, etc. This allows us to plan 'sprints' and informs conversations with the product manager when deciding on what functionality is likely to be included in our next monthly release. However, no official calculations are carried out by the development team. I wonder if this takes place higher up the management ladder. This is perhaps something I can investigate at my workplace, and see how project estimations is conducted.
