Software development effort estimation probably is one of the most disliked, even feared tasks in software development and computer science in general. However crucial, even the most experienced engineers succumb to common pitfalls from time to time or their estimates are off, too every now and then.
This is an especially striking phenomenon because software development effort estimation actually is a well–researched subject that a plethora has been written about. Starting in the 1950s IBM did a tremendous amount of research on the topic of software development management (one of whose key findings was that the optimal team size in software development is 5.4, a fact that still holds to this day and even more so with modern management methods).
So, it’s kind of a surprise that effort estimation still isn’t a more transparent and reproducible undertaking, even more so when considering that software development to a certain extent is an engineering discipline and engineering is all about creating reproducible results.
There are quite a few factors contributing to this, not the least of which is social pressure that comes into play when pitching for a new project and the prospective client is looking for the lowest price offer. This creates an incentive for unrealistically low estimations. This is a double bind that IT consultants and agencies can relate to particularly well. That said, even with realistic estimates there’s a variance of 30% in estimates by even the most experienced developers, which a is why fixed-price offers often are priced at the time estimate times 1.3.
Magne Jørgensen, researcher at Simula Research Laboratory, wrote a highly informative article on What We Do and Don’t Know about Software Development Effort Estimation, the conclusion of which is: Software development effort estimation is a complex task that depends on many factors such as historical data (with a potential for overfitted statistical models), software complexity and team productivity. To get such an effort right simply is very hard but there are some guidelines that can help with more accurately estimating your next software project:
- Develop and use simple estimation models tailored to local contexts in combination with expert estimation.
- Use historical estimation error to set minimum – maximum effort intervals.
- Avoid exposure to misleading and irrelevant estimation information.
- Use checklists tailored to own organization.
- Use structured, group – based estimation processes where independence of estimates are assured.
- Avoid early estimates based on highly incomplete information.
Anyway, if you’re dealing with software development estimates on a regular basis you should read this article since it contains do’s and don’ts of software development estimation and several hints for best practices.