How often your task estimates end up being accurate?

Hi, ladies and gents.

Here's my confession: I'm terrible with estimates. Partially because of my coding standards - people call me perfectionist (and I wholeheartedly disagree), but what about you? What's your story?

Almost always


Quite often


From time to time


Once in a while


Comments (21)

Marco Alka's photo

At work, I'd say most of the time, however we use Scrum, so we don't estimate time; we estimate complexity. We have a rough story with a given number of points and we compare the task to be estimated against it. We get a consensus using planning poker, and that's usually pretty spot on.

At home, for my private customers, I do have to estimate time, and I'd say I am right quiet often. I split up my tasks into small tasks for which it is easy to estimate how long it will take to implement them. Then I add them up and double the total. That's what I tell my customer. I usually finish way ahead (remember: I doubled the time), however the extra time lets me work on things in parallel or be spontaneous about how I spend my time.

Show all replies
Marco Alka's photo

Software Engineer & Mentor

Mihai Deta Planning Poker is the name of an agile/scrum technique. Roughly, you present a ticket to the team, and everyone gives their own numerical estimation of the complexity at the same time without talking about it. You can read more about it on Wikipedia.

Syed Fazle Rahman's photo

For me, right now, it's "Once in a while". I am still learning how to estimate time accurately. Hoping to master it soon. 馃挭

Gergely Polonkai's photo

I始m getting better, but it will never be perfect. What i noticed, though, is that i始m usually spot on when estimating others始 time.

Us humans tend to show ourselves as better than we actually are. That始s a fact and doesn始t really change between different cultures, either. So at our company we are currently trying to estimate how much a task will take for someone else (who will actually work on that task).

Another thing you should take into consideration is that time estimates are usually net times: 鈥渋f i can work on this uninterrupted, it will take this much鈥. However, this is almost never the case. We tend to get interrupted, and context switching is not cheap for most people. Thus, you should multiply the estimates at least by two.

Steven Ventimiglia's photo

Creative Technologist & Sr. Front-End Developer

A great answer, which is almost the polar opposite of mine. It honestly shows the importance of such a question.

David Angier's photo

After a long career, both developing and running teams, I am happy if the actual time is between 50% and 150% of the estimate. I try and adopt methodologies that focus on delivering value continuously rather than trying to deliver all the value at a specific point in time. If the product is always in a deliverable state, but maybe short on features, then it can actually be delivered at any time - in fact, it can be delivered continuously 馃槈

James Smith's photo

Very rarely, I always try to complete my task on time but I don't know how to contact MS Office that's why my task is delaying.

Getinfos's photo

Great job. Use Office setup . Microsoft Office setup is a suite of laptop productivity applications that are designed specifically to be used for office or business use. It is a proprietary product of Microsoft office Corporation and was first released in 1990.

Tekson roy's photo

I always complete my task which I set for my Geek Squad tech support company. Hopefully, you all do the same.

Getinfos's photo

Thanks for sharing this wonderful article. Install McAfee activate to save your device from antivirus.

Makhloufi lyes's photo

I think this is related to the experience, I mean the more one contributes to projects the more his time management is improved.

Gaponenko Andrei's photo

Scala developer & SOLID enthusiast

Yep, can't argue with that. Though that's mostly for tasks that are somewhat related to what you already created / modified yourself. Those can be estimated with a larger confidence. Unlike the other type of tasks when you're supposed to do something you've never done before.

Steven Ventimiglia's photo

I voted for "From time to time", since estimates based on planning sessions are dependent on the team member and their role. However, I would recommend thinking "shirt sizes" rather than "hourly". Also, review the past few sprints. I find this extremely effective for me in recognizing patterns within different workflows, which basically dictates what's worked in the past for similar issues (relative to the person that they've been assigned to.)

On a personal level, I would actually vote "Quite often". Because there's no guessing game involved, and I'm fully aware of other issues that life might throw me, which a Scrum Master would not be aware of.

illinka's photo

I'll call myself a realist. I can't say I'm exactly assessing the situation. But I'm careful in making my decision.

Nicolas Marshall's photo

Where's the "never" option ? Don't forget to handle every case !

Joe Clark's photo

I'm generally pretty close to my estimates if I can see the code in my head before I even begin. If it's something out of my comfort zone that I've never done before, I allow room for research and learning. But, if I pretty much know what needs to be done, my estimate includes what I think it will take me, including testing, multiplied by 3. This is my version of the Scotty Factor .

Show all replies
Joe Clark's photo

Full-stack developer specializing in healthcare IT

Ajinkya Hingne

j's photo

depends on the problem, my knowledge of the problem, my knowledge of the existing system.

Todd's photo

I tend to be pretty spot-on. I'm pretty good at giving conservative estimates at this point... Meaning, I factor in time for the unexpected, which almost always inevitably happens. I prefer to overestimate and outperform than to underestimate and underperform.