Software Estimation Techniques for New and Maintenance Projects

Multiple Software Estimation Techniques are available for estimating the efforts of a software project. However, not all techniques can be used for all kinds of projects. In this post, I am going to talk about 3 project scenarios and the appropriate estimation technique to be used for each.

New Software Project (medium to large sized)

Typically estimations are done at the pre-sales stage for bidding. The availability of information about requirements is limited. This makes the task of estimation very challenging and naturally it is error prone.

Pros – FPA estimation Technique

The ideal estimation technique could be function point analysis (FPA), which is an algorithmic estimation technique. FPA is a size and effort estimation technique based on features.This technique covers all aspects of software development like:

  • Number of interfaces
  • Number of screens
  • Data stores and interactions & more…

FPA also considers environmental factors such as type of application. A mid-sized project with 1,00,000 concurrent users expectations will have need more effort than 100 concurrent users expectations. This aspect is often overlooked in the other estimation techniques.

There are multiple environmental factors which can be useful for different scenarios.

Cons – FPA estimation Technique

It has a learning curve and requires some experience to be able to estimate using this technique.

Learning FPA

Here are some of the picks for learning FPA

IFPUG Documentation (Though a little dated)

FPA in Agile

FPA with examples

Maintenance Projects

I include change requests for enhancements and bug fixing in maintenance projects. These are characterized by much better availability of information. The system is already in place.

A WBS (work break down) based estimation technique is an ideal choice. it’s possibly one of the simplest estimation techniques.

In this estimation technique, we decompose the requirements into smaller units of work (by creating work break down structure). Each unit of work is then estimated for effort in days or hours. A sample break down structure is shown below:

Once the coding effort is estimated, you can roll it up to estimate the total effort including testing, requirement study etc.

Pros – WBS Estimation Technique

It’s a simple to understand estimation technique and can be easily learned.

Cons – WBS Estimation Technique

Just like any other estimation technique, it is also dependent on individual’s assessment and is prone to being biased.

New Software Project (Small Project)

We can use WBS estimation technique for small projects as well as discussed above.

Subjectivity in software Estimation Techniques

Software estimations are conducted by individuals and they are prone to being biased (not intentionally though). The reasons could be:

  • An expert developer estimating for programs, it will always be on lower side
  • A domain expert estimating the functionality
  • A normal professional typically underestimates

These reasons can be eliminated by simple modifications to any of the estimation techniques.

Eliminating subjectivity – Method I

In case of WBS estimation technique, we can ask two developers to give their estimation. This will average out the subjectivity without too much of effort. The estimation sheet will look as shown below:

We can easily take the average to arrive at better coding estimate. In case of FPA (typically done by project managers), we can ask two project managers to create FPA estimations and then take average.

Eliminating subjectivity – Method II

This is a more accurate technique to eliminate subjectivity. In this technique, a simple weighted average is calculated to arrive at the most likely estimate.

The estimation needs to created for the following scenarios:

  • Minimum time to finish (a)
  • Maximum time to finish (b)
  • most likely time to finish (c)

Then use the formula, best time to finish = (a+4b+c)/6


Software estimation technique has always been dependent on individuals. Many experts feel that software estimation is an art rather than a science. In my more than two decades of experience, lot of my estimations proved to be wrong. But I used the learnings to improve my next estimation. If you are expected to estimate, always be open to ask questions and learn from previous mistakes.

It’s also a good idea to refer to estimations of similar types of projects or ask your colleagues who have been involved in similar projects.

About Techcanvass

Techcanvass offers IT certification courses for professionals. We are an IIBA endorsed education provider (EEP), iSQI ATP (for Certified Agile Business Analyst Training) as well as Agile Testing alliance partner for CP-SAT certification training in Selenium.


Leave a Reply

Your email address will not be published. Required fields are marked *