DEV Community

Cover image for As a developer, how to estimate the time for a task?
Yogini Bende
Yogini Bende

Posted on • Originally published at

As a developer, how to estimate the time for a task?

It's hard to calculate the time you will need to finish the task, but it is equally important. Let's dive deep and understand how to do it?

Time estimations are one of the most critical metrics in project development. Though it is important for any project type, today, I will be talking about only software development projects (since I know them very well 😁)

Accurately estimating time for any task is very difficult but important as the whole project’s timeline is dependent on each of them. Most of the time we all underestimate a task leading to imperfect work (though perfection is a myth), buggy code, compromised work quality, and in the end, a frustrated team!

To be honest, I am no expert to write about this and in the early days of Peerlist, I have made blunders in calculating the time I will require to finish the task. But still, I thought of writing about this today since it is a very less discussed topic and as I am getting better at it day by day, I thought of sharing my ways with everyone reading this.

Before we start understanding my process, let's just first try to understand -

Why it is so hard to estimate the time for a given task?

1. Overconfident Self (I am a superhuman 😎)

Don’t get me wrong here, but we tend to forget our own past experiences and become fairly optimistic about ourselves. For example, I know creating a UI for a page would generally take me 4 hours, next time I will β€œthink” I will be able to finish that up in 2 hours!

This is my β€œassumption” based on what I β€œthink” at that moment of time without even realizing that if it generally takes me 4 hours, then how can I finish this up in 2? The optimism of my past experience do not make me take a better decision but overestimates my capacity to work.

End result, I fail in completion, get annoyed and affect the deadline of an overall project!

2. We don’t care enough to track how much time we generally take for small tasks

In the above point, seamlessly I wrote about 4 hours for a single UI page where that was a mere guess! If I ask you about the time required for any small part of your work, I am pretty sure you will also end up guessing time. This is common in all of us. We mostly don’t track our time much while working.

I know you must be feeling that tracking time might lose your productivity and focus right now, but it is like training yourself right now. If you understand it better, you will be able to estimate it better.

Enough of the whys, now let’s find solutions. Let’s understand -

How to be better at estimating time?

I have created a small model of task time estimation. Remember, this is what works best for me and I still keep on improving it. If you think you can add or remove any of these steps, you should! Also, though this sounds like a task in itself, trust me after a certain time it becomes a very normal process.

So, let me walk you through all the steps I take to estimate the time for a task.

1. Divide the task into small units

It does not matter how small the task is, if you can divide it into small units, it helps you understand the time required more closely. I mostly divide all my major tasks into small tasks that can be finished in 30mins (every unit should not require more than 30 mins to complete), this time should be based on what you think is best for you

2. Combine all the steps to find the final schedule

Now that you have divided your tasks into smaller ones, calculate all of them and the total time you will require to finish them.

Pro Tip: I write all the small tasks as comments in my code, and whenever one gets finished, I remove it. Helps me get that dopamine hit of completing and achieving something πŸ˜‰

3. Add 25% time as a margin

Though you created small tasks and added the correct time, still, there is a high possibility that you have misinterpreted something, something came up on time, or anything else, so always always always, keep this buffer on min 25% of the time.

Well, and who knows if you finish within time, this 25% can be a reward for you!

4. Assess the time after completion of your task

Out of all, I think this is the most important and most ignored one. Do go back to all your time estimates and start assessing which ones were correct and which ones you overshoot. But, for all those which you miscalculated, DO NOT think you performed badly at the task, it is always that your estimation was incorrect! This review will help you improve dramatically in estimations. This process does sound not-so-interesting but trust me, it will take you only 15 mins to do this.

5. Do not forget breaks

I am guilty of doing this! I always used to consider 5-10 mins of break would be fairly enough, but well, it's not! (Ohh come on, who can scroll Twitter feed and leave that phone aside in 5 mins πŸ™„). This might not be your case, but point is, that you should consider the appropriate breaks that will require for you to recharge yourself.

6. Use time tracking and Pomodoro

I will not ask you to subscribe for one more time tracking app here, because google timer works best for me here! I always start a timer of 30/40 mins, close all my non-required windows, mute/ignore all the notifications during that time and start working on that one task to finish it within that deadline. It's almost like a Pomodoro.

*How does it help? *

  1. You don't get distracted by other windows, notifications, etc.
  2. You time limit your task. So if you don’t finish it in time, you understand that pretty quickly.
  3. This helps you take breaks without feeling guilty.
  4. You start having a set schedule of your work.

I follow all these things and they are helping me get better every day in my time estimates. I believe in one thing, it is okay if you don’t know you will be able to do something in a given time, but it is not okay if you don't know you will NOT be able to do it in a given time! The latter will make things worst.

If you are still here, I appreciate your will to be better at your task! Hopefully, we all will crack this code soon. Meanwhile, if you find a better way to do this, I am there to listen/read.

Hope I am able to add some value to you with this article. If not, I am always open to feedback. I am mostly quite active on Twitter, so feel free to reach out there.

Shameless plug, join Peerlist. It’s a community-led professional networking platform for people in tech with very rich work profiles.

Keep building πŸ™ŒπŸΌ

Top comments (33)

jonrandy profile image
Jon Randy πŸŽ–οΈ • Edited

Almost 27 years of experience has taught me that estimation is a waste of time and a totally futile activity. Better to use that time simply getting on with the task

jwp profile image
John Peters

30 years for me. Only continuous delivery works in a 2 week sprint. Most valuable items only. No time estimates should ever be promised. Stick to Fibonaci estimates only.

jonrandy profile image
Jon Randy πŸŽ–οΈ

I just don't do them at all

Thread Thread
uzair004 profile image
Muhammad Uzair

what if client & Scrum master insist on asking time estimation fo reach task ? is NO or Can't a good answer ?

Thread Thread
jonrandy profile image
Jon Randy πŸŽ–οΈ • Edited

For Scrum masters, I've told plenty that I won't estimate. If they insist, I tell them to fill in a number themselves. It does make for some 'challenging' conversations, but I think it's worth it.

The happiest, most productive teams I've worked on have been ones that are free to self organise - working in cycles that last 6 weeks.

For clients, good communication and managing expectations is key. Generally just showing them progress from time to time is the best way. Making dated promises is usually a sure-fire recipe for disappointed clients.

Thread Thread
uzair004 profile image
Muhammad Uzair

thanks for sharing your experience, appreciate it.

dumboprogrammer profile image


sainig profile image
Gaurav Saini


brampayrequest profile image
Bram Hammer

For projects and bigger tasks I am almost always spot on about the time I estimate. However I always multiple it by 2 since I know I will have some high priority issues in between, a sidetrack which needs to be done, internal solving some stuff etc..

It's not really the task itself. The problem is more (for me at least) how much do we get interrupted, and are the deep-code-sessions long enough to make steps fast enough.

jwp profile image
John Peters

Effort appreciated but this is very similar to SDLC which Agile replaced many years ago, all for good reason. Never give a time estimate rather provide a Fibonaci number. Convert to 2 week sprints and only focus on most value items for each sprint. That way impediments can only impact a two week period. Everything's tracked on a board.

imcheesecake profile image

I never estimate. Where I work now we just agree if a task is S, M, or L, meaning shirt sizes.

S = easy task, no need for any digging or help from other teams/third parties.
M = A bit bigger than S. Might need some outside help or at least some digging.
L = Will take a while and most likely needs a lot of outside help.

And since I have like a billion meetings everyday even a S can take me a week to complete in actual time.

perssondennis profile image
Dennis Persson

Pretty well-planned approach you have there. I think it could work quite good. In my opinion it's quite time consuming though. You have to remember that time estimations normally involves many people, so an hour estimation meeting can be many more hours effectively.

I would suggest using agile metrics. In that way you can plan in points and the points will automatically correspond to a certain amount of time based on the actual time it takes to develop. The process is described here.

vulcanwm profile image

This is really helpful!

andrewbaisden profile image
Andrew Baisden

Great article. I use apps like Centered for tracking my time and productivity it has made a big difference for me.

silviaespanagil profile image
Silvia EspaΓ±a Gil

Well in my team we have done an estimation agreement so we all kinda estimate the same way. We work on two week sprints, divided by goals each goal shredded in little tasks.

The tasks we estimate not by time but by storypoints and they have no relation with the task time but the task complexity, possible dependencies and how critical it could be. An the estimations are done using Fibonacci.

So, things like, creating a new module could be a 13SP something like adding a service 5SP, an changing a lokalise string or adding a tracking for Firebase could be a 1SP.

This take no time at all to do. We add the estimations during refinement. And after a task is done if we think it was wrongly estimated we have a special field with that only to see if this is getting common and we have to revisit the agreement or if it was a thing of one time only.

The system also help us to create like a team average so we can plan better sprints

mmuller88 profile image
Martin Muller πŸ‡©πŸ‡ͺπŸ‡§πŸ‡·πŸ‡΅πŸ‡Ή

Nice article! breaking tasks down in max 30 minutes is my favorite :)

joelbonetr profile image
JoelBonetR πŸ₯‡

That can easily lead you to micromanagement, loosing valuable time in bureaucracy and assigning the tasks beforehand so no teammates are self-assigning tasks from "your" feature.

syeo66 profile image
Red Ochsenbein (he/him)

Estimates only ever tells you one thing: How well you did in estimating the task.

Project management tends to not like this truth...

frankfont profile image
Frank Font

True; but also they can become self fulfilling prophecies when not unrealistic.

syeo66 profile image
Red Ochsenbein (he/him)

Yeah, true... why do it faster if there is no need...? Makes it counter-productive in the end. So, decide: is it a good tool? ;-)

Thread Thread
frankfont profile image
Frank Font

One practical aspects of prediction is individuals predicting what they can complete in one workday. Walking away from partial work that’s at a good stopping point is always better than walking away from a mess you’ll have to look at again the next day. For multi-day efforts this is an indispensable skill that I believe all successful developers eventually grok.

mcsee profile image
Maxi Contieri

25 years of development, 20 teaching at the university

Both worlds conclude the same:
Estimation is a waste

explorer14 profile image
Aman Agrawal

In software as in everyday life, estimating time is hard. For software in particular my typical response to "how long will it take?" type questions is:

  • what do you want this information for? and,
  • do you want a more accurate estimate than a number out of a hat? If yes, then I will have to do a deep analysis of the problem, constraints and assumptions, architecture, breakdown of dependencies, team availability and skills in that area, to give you an estimate which should be in the ballpark.

By this point their eyes glaze over and they go, "number out of a hat is fine, I just need to put some numbers on a roadmap for my presentation to the board next week!" at which point I oblige them duly with a number that's on purpose a bit bloated and everyone is happy. No expectations are broken, no business loss occurs and developers are not flogged to go "faster"!

I have also found that once an engineering effort is underway, keeping people in the loop about progress or even impedances every sprint via show and tells and demos, is the most effective way to have them stop asking such questions to begin with.

victoria_mostova profile image
Victoria Mostova

Hello Yogini! I completely agree with the insights shared in your article. As a developer, it can be a challenging task to estimate the time required to complete a particular task accurately. By breaking down tasks into smaller, more manageable parts, using historical data to inform estimates, and accounting for unexpected delays or setbacks, developers can improve their ability to estimate development time and deliver high-quality work to their clients. I really appreciate the practical tips and techniques provided in this article on how to estimate software development time. Thank you for sharing this informative post with the development community!

frankfont profile image
Frank Font

Practical principles like the ones you shared here help!

My colleagues and I have tried to make the art of practical effective estimation a lot more accessible in by applying principles from the popular book β€œultra forecasters β€” the art and science of prediction”.

cmiles74 profile image
Christopher Miles

A lot of good ideas here! For me, padding my estimate has been a huge win. Combining that with assessing how long a task took (and maybe what about it made it take longer) has helped me provide estimates that I either meet or beat.