Share with your network!

In the second part on the blog series on estimation, we dive into understanding the various techniques available for estimation. We talked about Project estimation challenges in the first part

Estimation is a tough nut to crack, even for a seasoned programmer. The reason being every project brings its own unique set of challenges, domain, technologies, people and other complexities. Software domain experts have explored different approaches, systemic and others, to compute project effort. In this article, we introduce some of the common methods that are used for estimation.

  • Expert judgement: For many projects, we rely on experts with the required domain and technical know-how to help understand the effort that needs to be invested. This is not necessarily done on the basis of the opinion of only one expert or only at the project level. Many a time, different experts pitch their views on different modules or tasks.
  • Analogous estimation: This is similar to expert judgement except that instead of relying on the experience of individuals, we rely on data from past projects that the company or the industry has been involved in. So, if a messaging service was developed in one month earlier with a team size of two and X technology, the extrapolation is done to figure out how quickly it can be developed with a team size of four and X’ technology. The challenge here is to pick the right analogy as the basis, which is often harder than one can imagine given the number of variables in play (technologies, tools, people skills, etc.) If the right analogy is picked, the estimate can be fairly accurate.
  • PERT (Program Evaluation and Review Technique): This technique is a risk reduction method where it takes the optimistic and pessimistic estimates and averages out the numbers by giving a higher weight to a more likely estimate.
    E = (O+4M+P)/6, where, E – Effort, O – Optimistic, P – Pessimistic, M – Most Likely
  • Though PERT is a methodical approach, many still consider this as a guess, because there is no actual logic or reference for the calculation of O, M and P – they are still based on individual judgement.

  • Wideband Delphi: Here, we move towards a consensus based approach and hence one step closer to introducing a system to the madness. In Delphi, estimation is done through multiple iterations. In every iteration, team members provide their individual effort estimate of the task/module/project and then regroup to hear each other’s estimates. Then, a discussion happens to understand each other’s estimates and questions are asked on the decision points. Based on this, the next iteration begins and this brings the range of their estimations close enough for agreement.
  • LOC: Here a computational measure such as Source Lines of Code (SLOC – physical and logical) is used. While, in order to demonstrate a project’s hugeness, KLOC is often quoted as a basis, LOC is often considered unreliable to make an effort estimate because it is highly dependent on syntax, styling and coding efficiencies of a developer.
  • Function point: Function point (FP) is one of the most systematic ways of estimation. One thing it really helps nail down is the project complexity. It’s done from a user point of view, so the technology is irrelevant for the calculations.
  • A good understanding of the input, output and storage are important to estimate the FP of a project. The key components that are considered here are External Input, External Output, External Inquiries, Internal Logical files and External Interface files. For each of these components, based on the data element types (DETs), return values, the complexity (low/medium/high) is evaluated and function points are calculated appropriately. The summation of FP of each of these five components gives the total FP number.

    Since it’s a unit of measure of estimation like hours or miles, function point is very useful to compare against previous projects, especially in huge firms which have repositories of past project data. It is also a good tool for allocating project cost and mapping other metrics (E.g. number of defects/FP). FP estimation is good for large projects and to come up with a high level estimate and cost calculation at the beginning of the project. It is not found to work well for maintenance projects.

  • Use case point: This is again a formula based approach to project estimation. The reference here is the number of use cases and based on the technical and environmental complexity of each use case, weights are assigned and a total number called use case point is arrived at.
  • UCP = TCF * ECF * UUCP * PF

    Technical Complexity Factor (TCF), Environment Complexity Factor (ECF), Unadjusted Use Case Points (UUCP), Productivity Factor (PF)

    This method relies on having a lot of technical and design details in place before going ahead with the estimation. So, that makes it a bit difficult to use this method in the beginning stages of a project.

    Typically, people find that use case points are quite larger than the actual effort because of the exhaustive list of technical end environmental factors that are being considered. This is probably good in that there is some inherent padding available, but experts usually tend to take a look at the use case points and apply their knowledge and experience to it.

    A slight deviation from this is test case point calculation which is used for testing projects where the reference is test cases instead of use cases.

    In this article, we discussed a few frequently used estimation methods. Certainly, the list is not exhaustive as there are other methods like COCOMO, Monte Carlo, story points, etc.

    One thing that should be obvious by now is that usually a mix of models are used based on the situation you find yourself in. For example, in some scenarios, a bottoms-up approach is used whereas in some others, a top-down approach is found convenient.

    Usually, at the start of a project, FP may be used but at a later stage when a detailed WBS is available, Delphi could be used at a module level to narrow down the range. Also, the approach varies based on whether you are working on a from-the-scratch project versus a maintenance project or large scale versus small scale or external versus internal projects.

    Watch this space for the next part in this blog series, in which we will focus specifically on Agile estimation methods.