How often your task estimates end up being accurate?

Almost always

6%

Quite often

26%

From time to time

36%

Once in a while

32%

94 votesClosed

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?

Learn Something New Everyday,
Connect With The Best Developers!

Sign Up Now!

& 500k+ others use Hashnode actively.

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.

Mihai Deta's photo

developer something something

what do you mean by "planning poker" ???????

Marco Alka's photo

Software Engineer, Technical Consultant & 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 馃槈

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 .

Ajinkya Hingne's photo

I am surprised to see that people multiply the time by 2-4 of the actual estimation. I have never done this - I mostly end up giving an actual estimation and then adding a buffer of around 25% of the total estimates. Looks like I have been doing it all wrong!

Joe Clark's photo

Full-stack developer specializing in healthcare IT

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.

Want to read more?

Browse featured discussions

漏 2020 路聽Hashnode