Project estimates : the necessary guesswork

An estimate is a prediction of the duration of the work required to complete a project.

Usually, estimates are calculated in days of work, which could be easily converted to show the overall labor costs when multiplied by the daily rate (if paying by the hour).

The most common way of estimating is the so-called Bottom-up Estimation method, where the project gets split into smaller chunks of work, such as components, epics, features, stories or tasks.

The sum of all individual estimations then offers the grand total.

Estimating smaller chunks of work is far more accurate. It also allows managers and other shareholders to gauge what effect various parts of the requirements will have on the total cost of the project.

A detailed estimate is not a simple task.

Depending on the project scope it could take anywhere from few hours up to few days (and even more for larger projects).

Most of the work goes into defining project details, deciding on the technology that will be used, and splitting the scope into smaller, more manageable tasks.

Estimates are a group effort. They necessitate close collaboration between different types of developers and other specialists, designers, project managers, and, of course, the client (or product owner).

The Devil is in the details. In order to accurately estimate the development effort, the team first needs to know the exact scope of the project, what all the features will do and how exactly they will work. As well as, what technologies will be used, what the UI will look like, and how different components of the project will interact with each other. Other project limitations should be taken into consideration too, such as the budget, deadlines, and prioritised features.

Every estimate goes through the following key stages.

Step 1: Collecting requirements & information

The key here is gaining a deep understanding of all project details and making them accessible to everybody in the team.

Ideally, the project owner should provide plenty of business and technical details, which might include:

– Business goals – Scope & requirements – Features list – Designs – Other technical documentation

Step 2: Research & evaluation of possible technologies

This involves choosing the development language and platform, software architecture, third-party frameworks and libraries, server & hosting providers, and so on.

There are a lot of decisions to be made, all of which affect the final estimate and the project itself.

The quality of the information gathered in the first step will eventually determine the choices made here.

Step 3: Splitting it all up

After all the details are clear and all key decisions have been made, it’s time to split the scope of the project into functional components. This will then get divided up even further into individual features and then into small, manageable tasks.

How the splitting is done is based on the project. But the high-level topics could be:

– Graphic design – UI implementation – Features development – Backend development – Admin panel development – Testing & bug fixing – Documentation – PM & communication

Step 4: Evaluating the effort

Finally, this is the stage where we estimate each small task. Here at CodeControl, we try to keep the size of individual tasks below one day of work.

If a task requires a higher estimation, then it is divided further into smaller chunks (if appropriate).

Estimating is essentially making an educated guess based on knowledge and previous experience.

Many features of a project could be well-known, trivial tasks that are present in almost every other project. Consider a Facebook login in a mobile app, a simple ‘Contacts’ screen in a website, or a PayPal integration in an e-commerce site. All of these are simple, almost standard tasks that an experienced developer has probably implemented many times in the past. Because of that, they can be estimated with a high level of accuracy.

But there are some complex tasks, which require a higher level of creativity or experimentation, that cannot be so accurately estimated.

We introduce the risk multiplier index for cases like these.

In our estimates, each task or feature gets two values: а reasonable prediction of the time needed to implement it (the realistic estimate) and a risk multiplier. Multiplying these two values gives the pessimistic estimate.

Trivial tasks or tasks that can be estimated with high-level certainty have a risk multiplier equal to 1. So their realistic estimate equals their pessimistic one.

Other tasks require a risk multiplier between 1.2 and 3 (in rare cases). This accounts for uncertainties like higher complexity, unproven technology, exotic architecture, experimental implementation, and so forth.

Working with Rough Estimates

Although detailed estimates should be based on plenty of information, full project specs, and final designs, some projects are still in their planning phase when an estimation is needed. This brings about a lot of uncertainties and increases the risk of an incorrect evaluation.

To account for that, we again use the risk multiplier index and create what we like to call a ‘Rough Estimate.’

In a normal estimate, the difference between the minimum and the maximum grand total is up to 25% (but often less). For a rough estimate, this difference is usually above 50% and may therefore double the minimum estimate.

When Not to Use an Estimate

Estimates are a great source of information for the management team. Plus, they have a significant role in making astute business decisions.

But there are few things to consider…

Estimates are (educated) guesses

They are not 100% accurate, so don’t freak out when one task takes more time than its maximum estimated effort.

It’s often the case where some tasks are underestimated and others are overestimated — they cancel each other out in the end.

Estimates are not deadlines

Estimates are often conveyed in developer days. Yet don’t assume that 8 hours of development work actually equals one working day!

Recognise that every developer does tasks during the working day that aren’t ‘straight-up’ developing. For example: answering his boss’s emails, researching a new technology, participating in group calls and sprint meetings, making estimates for other projects, etc. (if you’re looking to improve your developers’ performance, check out some of our ideas here).

Bear in mind that, on average, one working day consists of between 6 and 7 hours of active development work.

Which means that a project estimated at 20 development days (4 work weeks) will actually require about 5 weeks to be fully completed.

Also, don’t forget to take public holidays and possible sick days into account.

Adding a developer doesn’t halve the required time

Estimates don’t take into account how many developers will simultaneously work on the project and any time alterations that will result from that.

You would assume that, by adding an extra developer, a 20-day development project could be easily done in two weeks instead of four, right? Not exactly!

Adding more developers to a project also requires some additional time spent on communication and coordination, which you should take into account.

Overall, detailed estimates require a lot of information, research, experience, and above all — collaboration.

Good estimates keep the expectations of the development & management teams in sync. They clearly communicate the final scope & details of the project. And last but not least, they can be used to check if development is on track.

Carrying out an effective estimation is the first step in a successful project.