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:
- The client wants to know when the project will be finished and how much it will cost
- The software development company wants to know how the time of its developers will be allocated and how much they will earn for their work
- The developer wants to know how to organize his/her work in the coming days, weeks or even months
- Project estimation is essential for sustaining a reliable, professional relationship between the parties involved, through transparent communication and clear requirements
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.
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:
- Projects change over time so that they may take longer or shorter
- Sometimes things look better than they are, e., something seems almost done, but it isn’t
- Projects contain some unknowns, and these unknowns can only be learned over time, during the project
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:
Now it isn’t so overwhelming, is it?
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.
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: