Why is Project Estimation Hard and How to Get Better at It?

Being a lumberjack requires not only cutting, lifting, carrying and stacking trees at a designated location, but also estimating the time needed to do such things. And it is similar for developers, who – apart from coding, fixing and deploying – need to know a thing or two about time management.

However – in both cases – it’s hard to do this properly and accurately.

Fortunately, there are some tips and tricks to help you to do so – and I don’t mean being a lumberjack.

Why do we need project estimation?

Apart from pure technical skills, every developer has to know how to estimate the time needed to build a particular product or feature, or just to complete a specific task. That is fundamental for each of the three interested parties (client, software development company and developer) for a few reasons:

Sounds like something indispensable to successful project execution and a feeling of satisfaction at the end, right?

Unfortunately, estimating software development time is easy only on paper.

Why is that and how to resolve it?

The longer you think about it, the more you think it’s a… paradox! But do you know why?

Let’s put it this way: if you have built something before, you should know how long it took, right? However, if you’ve already built it, you wouldn’t be building it now. It all boils down to the fact that you can’t know how long it will take!

All right, never mind.

Maybe it’s not possible to predict the exact amount of time needed. But looking at the reasons why it is so hard may help us to get better at it.

Projects are never the same

99% of the time, projects aren’t the same, so even if you have built something similar in the past, your current project probably won’t be identical. Therefore, it’s hard to predict the exact amount of time needed to finish it.

Anyway, you should be able to at least give a time range forecast, e.g., three to seven days.

Giving estimates immediately during meetings

This mistake has a psychological background, and it’s simple – during the meeting, you may feel the temptation to give a lower estimate to make the potential client happy. Stress and time pressure aren’t good advisors. It’s usually better to ask for time to think about it with a cool head.

Time underestimation

In general, people usually tend to underestimate the time needed to finish the project in front of them. And developers and project managers are no different. That happens because:

Solution? Add – even only in your head – a time margin from 20% to even 50% (in the case of new things) to finish a particular task. Even if you use that time to the fullest, in the eyes of the client, you will finish on time!

Lack of task tracking in the past (and present)

Not doing task tracking during previous projects leads to the inability to predict the time needed to finish particular tasks similar to ones waiting in the current project. Task tracking – not only of the time needed but also of what tasks we have finished – should be done at least once per day, at the end of it. It’s a basic principle of time management and the basis for development (not only when it comes to software).

If you want to improve in this field, start using a time tracking application such as Toggl until it becomes a habit and a part of your natural workflow.

Not being flexible (sometimes)

Who said that a project or task should be estimated in hours, not… points? If possible, try the second method and use a scale of one to eight, and then compare completed tasks. What you should pay attention to are execution times of similar tasks, marked with the same amount of points. That will help you to estimate the future speed of execution.

Large tasks instead of smaller ones

I won’t give you specifics such as data from American scientists, but simply looking at the big task – such as “build an application” – overwhelms people. It petrifies us. We don’t know what to do, where to start and whether we can complete it. Luckily, it’s easy to eliminate this issue. Or, at least, minimize it.

Let’s look at an example.

Overwhelming task: build an application.

Overwhelming task after being broken down into smaller tasks:

1. Choose an idea
2. Write down core functionalities
3. Prepare the first sketches
4. Plan application’s UI flow
5. Think about the shape of the database
6. Create UX wireframes
7. Look at solutions and pick a language
8. Start coding!

Now it isn’t so overwhelming, is it?

Parkinson’s Law

Ever heard this term? In short, it states that work expands, so it fills the time allocated to complete it. How does this affect time estimation?

It’s common for people to allocate a specific amount of time to complete a particular task when it could be done faster, even twice as quickly. That results in an extended finish time of the whole project.

The solution? Same as above (dividing the task into smaller ones), or try running Agile sprints.

Not keeping the developer’s background in mind

Every programmer has a different set of skills and different experience, so if you are a project manager, you must consider that. Know your people not only in terms of strengths but also weaknesses. Be aware that ten people will probably finish the same task at ten different times.

Conclusion

Even if it seems hard at first or if experience tells you it is difficult, it’s time to believe that nothing is impossible, certainly not estimating software development time properly.

Set a period, but do it pessimistically, then divide larger tasks into smaller ones. Help yourself along the way by using time trackers, try running sprints, and keep in mind that everybody’s different and needs different time and conditions.

Here you can see last articles from Bartek:

1. The Most Important Metrics That Matter for Your App

2. Handwritten Digit Recognition on Android

3. SoftwareHut’s Best Android Practices