Estimating software projects: 10 tips for software project estimation

Estimating software projects: 10 tips for software project estimation

Estimating software projects is not an easy task, and if you do not have enough experience, the margins of error can be huge, and the consequences are generally not favorable. The following advice will be essential to succeed in the development and to avoid going over budget and wasting time.

Estimating software projects: Tips for software estimation

Estimating software projects is not an easy task, and if you do not have enough experience, the margins of error can be huge, and the consequences are generally not favorable.

With the purpose of reducing those margins, I decided to give you some tips that can be used when you are making a software project estimation, which will be essential not only to succeed in the development but also to avoid going over budget and wasting time.

Do not miss this reading: Software quality or price: Which one really matters?

Estimating SOFTWARE PROJECTS, what is it about?

If we stick to a dictionary definition and we want to express it in a simple way, we can say that an estimation is a prediction of how much time a project will take and how much it will cost (in economic terms). Another way to look at this concept is by analyzing the estimation process either as a science or as an art.

When the software project estimation is conceived as a science, it focuses on enhancing the processes, which is why it requires high mathematical knowledge as well as the control of techniques that, by using sophisticated tools, look for estimations with a margin of error of less than ±5% or ±10%.

On the other hand, when the estimation is seen as an art, the techniques and procedures used are simpler and more effective, making the margin of error around ±25%. I will focus on this last approach to give you useful advice for proper software project estimation.

1. Identify your goals and commitments

Estimating software projects: Tips for software estimation

In a software project, clearly establishing goals and commitments is a key factor. Knowing from the beginning of the development the objective you want to meet to fulfill your company’s commercial needs, as well as those promises (commitments) that a particular functionality/system will be ready by a certain date, are the basis for facing any kind of estimation.

The above is important because the principal aim of the software project estimation is not to predict the result of a project but to determine if the commercial objectives of the project are realistic enough to allow the project to achieve the scheduled commitments within the estimated times.

2. Know the functional scope of the project clearly

One of the most important aspects for sizing a project is to know what you want to develop and what its reach is. In certain situations, there are detailed functional breakdowns with reference documentation that allow you to comprehend the reach and everything that comprises the system to be estimated. However, that does not always happen, and that is when the estimation task becomes more complex and uncertain.

In these situations, it is necessary that the estimator generates the functional breakdown according to the meetings held and thinks of the commercial needs of the project and the different commitments. Therefore, it is recommended to execute the following:

  • Coordinate meetings and calls to accomplish greater understanding.
  • Research similar systems that serve as a reference.
  • Understand in detail the industry and the type of project.
  • Validate and prioritize the functional requirements created.

3. Keep in mind the non-functional requirements

10 useful tips for software project estimation

Unlike the functional requirements that describe ‘what’ the system has to do, it is important to consider the non-functional requirements, which describe ‘how’ the system has to work and cover the rest of the requirements not covered by the functional requirements.

For example, “The system must respond with a latency of less than 3 seconds”. Some of the typical non-functional requirements are below:

  • Scalability
  • Performance
  • High availability
  • Security
  • Usability
  • Interoperability
  • Maintainability

Depending on the type of project or industry, each of these non-functional requirements may have a different level of importance, and according to the context of the project, the complexity to implement them can vary.

4. Determine priorities

Many times, the estimations and restrictions of the project (budget, timing, resources, etc.) make achieving the proposed goals a bit complex. In these situations, it is important to know and consider the most significant functional priorities so that you can focus on the most important topics.

In the worst-case scenario, the least critical matters can be postponed for another phase of the project.

5. Align plans with the estimations, goals, and commitments

Estimating software projects: Tips for software estimation

Estimations are the basis for planning, but plans do not have to be the same as estimations. If the estimations are too different from the goals, the project plans must recognize that difference and consider it a high risk.

On the other hand, if the estimations are similar to the goals, the plans will assume a lower risk. The following are examples of the planning considerations that depend on the estimations:

  • Identify the critical path of a project.
  • Create a complete structure of work breakdown.
  • Prioritize functionality for the delivery.
  • Divide a project into iterations.

6. Choose the right strategy for estimating

Depending on the type of project, its complexity, the information present, the amount of requirements, and the delivery times of the estimation, it is necessary to think and choose the right strategy. We can look at some of these here:

  • Traditional estimation: It is probably the most common strategy, and it consists of choosing a requirement and assigning it a time value according to the complexity detected and the experience the estimator has in the development of those types of requirements. To gain greater precision, you should divide the requirement into components (presentation, business, database), and determine a time for each of them. Then, the whole estimation of the requirement will be the result of the summation of the estimation of each component. The strategy of dividing into components is not the best if there is not enough time or if the amount of requirements to estimate is too much.
  • Estimation by order of complexity: It consists of assigning an order of complexity to all the requirements to be estimated and estimating a representative sample of all the requirements using the traditional strategy (from the previous point). The next step is to extrapolate the value of the traditional estimations from the requirements pending to estimate, according to the order of complexity. For example, if there are 100 requirements, we follow the next steps:

Estimating software projects: Tips for software estimation

  1. An order of complexity is assigned to all the requirements (e.g., Story Points: 1,2,3,5,8,13).
  2. A representative subset of requirements is estimated traditionally (e.g., 10).
  3. The estimations are averaged by order of complexity (e.g., if 3 requirements were estimated with a complexity of 2, these 3 estimations are averaged).
  4. The non-estimated requirements are taken and assigned the value estimated in the previous point, according to the order of complexity.

This option is very useful when the amount of requirements to be estimated is large.

  • Estimation based on analogy: The software project estimation based on analogy is founded on the principle that the real times obtained by the company in a similar previous project are the best indicators, which help to predict the performance of a future project much better than when an estimation is made from scratch. To that end, the company making the estimation must do the following:
  1. Have extensive experience.
  2. Keep track of the times of the previous projects.
  3. Maintain a knowledge repository to detect similar projects.
  4. The estimators must be trained to adapt the analogous estimations and manage the knowledge repository.
  • Estimation by team: This consists of distributing the requirements by components, system modules, or some other criterion, which, if possible, offers independence to groups of specialized or dedicated estimators. Each group will estimate the set of requirements assigned by following one of the previous strategies, and then the work done by each one will finally consolidate into a single estimation. This strategy is recommended when the amount of requirements is very large.

7. Detect and register the assumptions chosen for the estimation

When an estimation is made, there is a lot of uncertainty involved in the functional understandings of the application to be estimated, and solving all the doubts is not always possible. Therefore, it is important to record all of those assumptions that influence the estimation and the planning of the project so that the person responsible for evaluating the estimation is informed at the right time.

This reduces the risk of misunderstandings by ambiguities or by information not provided.

8. Check the estimations with other estimators

Estimating software projects: Tips for software estimation

One way to gain greater precision in software project estimation is to hold meetings with other estimators once the estimation is done to check each of the requirements and explain why the times were assigned that way.

This is how it is possible to detect cases not contemplated or, on the contrary, adjust the times of overestimation.

9. Use tools for estimating

An important added value in software project estimation is the use of tools, which not only helps to automate the process and make the estimation follow a line, but it also allows you to capitalize on the knowledge of maintaining a history of estimations to which we have access at any time. The use of tools also makes the group tasks of estimation easier, as well as obtaining metrics and reports.

10. Other times that must be considered

In general, when the assigning of times of the requirements is made, only the development stage is considered; however, we must not lose sight of tasks such as testing, functional analysis, meeting management, infrastructure management, deployment, and project meetings. Sometimes the development team can carry out these activities, but in other cases, you will need the presence of specialized profiles such as testers, functional analysts, designers, and PMs.

To Sum Up

Estimating software projects is not a trivial task. The most advisable thing is to have a group of estimators experienced in different industries and types of projects. They should work together to reach a clear understanding of the scope, goals, and commitments and to use the recommendations made to reduce delayed uncertainties in order to get the most accurate estimation, both in times and costs.

White Paper

Comments?  Contact us for more information. We’ll quickly get back to you with the information you need.