Most people do not know how to adequately assess the time it takes to complete tasks. Oh, how it makes them sometimes nervous... Here, and "the deadline sneaks up unnoticed." And they are reinsured by more than 500% just in case (still not enough). And managers try to squeeze "deliberately inflated deadlines" to promise something more acceptable (a common management disease). And vague mumbling instead of specific numbers (this is rather a developer's problem).

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law. — Douglas Hofstadter

Personally, I, and I'm sure that almost all of you, hate questions like "When will it be ready?", but they are important at any time in a project that is considered under control.

To actually estimate the time for some of your or your team's work, you need to make some preparations.

Step 1. Understand customer requirements

If you do not know the ship's destination, how can you tell how long the journey takes?

Start by identifying all the work that needs to be done within the project. This includes, for example, functional and non-functional requirements (and it should be noted that sometimes it is difficult to do it at once and maybe the process needs to be done iteratively). As part of this, make sure that you have time for meetings, reporting, communication, testing, and other activities that are critical to the success of the project.

Step 2. Order these activities

Now list all the actions that you have defined in the order in which they should take place.

At this point, you do not need to add how long you think the actions will take. However, you may want to mark any important milestones. For example, you may want to get documentation on another component of the system before you start integrating.

Step 3. Risk management step

List all assumptions, exceptions and limitations that are relevant.

At the initial stage of the project, a brainstorming session should be conducted to determine the risk. The assumption that your project has no risk is wrong — every project has risks. And if you do not see them, you are looking in the wrong direction. When risks are not identified and measured, it means that you no longer have control over the project and the time it takes to complete it. You rely on luck — that these risks that you have not thought about can materialize and increase the time it takes to complete the project or spoil the project.

Step 4. Make the estimates

There are several methods to estimate time:

Expert Judgement

In fact, this is the process of making an estimation with the involvement of experts in this necessary field. It can be a single guru or you can involve a group of multiple experts in this area.

Experts make their judgments about the estimation (time or $). After that, you can average all the estimates, and during the discussion, you can try to come up with a common decision. Involving the experts in the discussion of the options is, of course, more efficient and will give a more accurate, reasoned and verified estimate.

Three-Point Estimating

One of the most common and simple methods. This method first identifies optimistic (O = Optimistic), pessimistic (P = Pessimistic) and realistic/average (M = Most likely) estimates.

The values of P, M, and O (in hours, days, $) are determined by the brainstorming with the project team. Such questions are asked: "How long will the project take, if all goes well, there will be no risks and problems?", "What can be the most negative scenario and how much time/ effort will it take?" etc. Then the obtained values P, M and O are substituted in the formula: (O + 4 M + P) / 6.

The result of the calculation gives a close realistic estimate. This formula allows, on the one hand, to take into account possible positive and negative scenarios and, on the other hand, to "smoothen" their impact and obtain a more realistic assessment value.

Cost of Quality

Quite an interesting technique, at first glance. Estimates are made only for developing functionality, without taking into account bugs and problems, as if we immediately implement the perfect software without defects (I have never seen such a unicorn). And then, it is calculated how much extra time and budget it would take in reality to handle the bugs and problems to bring the software closer to this "ideal" state.

In assessing the cost of software quality assurance, you can analyze and consider the following areas:

Expenses for defect prevention activities

Cost of testing

Correction of internal errors

Fix external integration issues

The cost of installing and configuring the software based on the real environment and data

Analogous Estimation

Here, we rely on past experience in dealing with such problems or projects. The main step here will be to search for possible analogies, to identify similar tasks.

In this approach, you need to decompose the project into tasks that are already known to the team and have been solved in the past (or bring to similar tasks) and unknown tasks that can be estimated in another way.

For example, if a few months ago the development of the site cost 8000, and you need to develop a new similar website, then by your estimate it will cost 8000.

Parametric Model

It is one of the most accurate and flexible estimation methods. Its essence is to build a certain parametrized forecast model based on past experience, available data, and metrics, statistics.

In fact, it builds a special mathematical model that allows you to track how the final estimate changes depending on the initial parameters. Such dependence can even be visualized. It will help to analyze the boundaries of the estimate deviation from the average and see what can affect it.

For example, if last week it took me two hours to complete two tasks and this week I have four tasks to complete, then I estimate that it will take eight hours, assuming that the tasks are more or less the same.

Bottom-up Estimation

This method is similar to expert estimation, only, in this case, the estimation is made not for the whole project, but separately for its parts. It is a kind of decomposition of the project into different stages. How it works: we collect expert opinion, for example, from specialists on analysis, development, testing, software support. We summarize their assessments together, add the time spent on interaction to them and formulate a general forecast.

In other words, we collect an estimation in parts, knowing, how much time is necessary for each of the participants of the software development process and taking into account additional risks.

Conclusion

I think it may be preferable to mix several techniques, such as a bottom-up estimate with a three-point estimate to measure parts of the project, in order to obtain more accurate results.

You need to teach people how to make assessments, especially in the IT field. This is important for the success of the project, for the success of the people involved and of course for the satisfaction of the customer.

It is not always possible to correctly interpret the customer's requirements and one should always expect that the customer will come up with something new or modify something that exists in the specifications. When a person doesn't want or doesn't have time to understand the requirements or to decompose the project, you can always hear different evaluation multipliers either pi(3.14...) or e(2.71...). The coefficients are not small, and their spread can be large. But this is a problem of careless attention to details or laziness of understanding all the above. It is clear that the estimation requires resources, sometimes serious, but the more attention to detail, the more accurate the forecast of completion time will be, especially if we have a team that has already developed and implemented similar projects.

Unfortunately, teaching someone to pay attention to the details is difficult and time-consuming. But it is necessary, despite the resistance.