177. How Do I Estimate Tasks Correctly? How Do I Estimate Time Accurately?

[@CyberAbyss007]

Good video Tim! Under promise, over deliver. Do it, every time. Your reputation depends on it. Be honest and don't be afraid to negotiate. Time vs. quality or features.

[@IAmTimCorey]

Absolutely.

[@itaylorm]

Definitely how I approach it. Hard if you cannot get the client to define priorities

[@manuelgamezz]

Thank you Tim, In my experience was a similar tips with my team, for example I told them that they need estimate internally and other estimate externally in presentation to the client adding more time for the originally. This is because the clients or the managers don't know the problems that could be occur(the majority of time all could be change). One video that you could do is about the cycle of the project: what is the order from the beginning to finish on your experience. Example(1.- First: functionality, 2.- Design, 3.- Testing, 4.- Refactoring code, etc)

[@keithcourneyea1609]

Great idea on a series

[@carrikmcnerlin1770]

A joke answer to this question that has served me well - whatever your estimate is, double it. If you're unsure of your estimate, triple it instead.

[@IAmTimCorey]

Yep, that can work.

[@Yunyun-o6m]

Really helpful ❤ Thank you as always tim ..been watching your videos for 10 yrs 😊

[@IAmTimCorey]

Thanks!

[@kurtrichter5500]

One thing that worked well for me was creating estimates based on how it was described in Uncle Bob Martin's book, Clean Coder. He basically described breaking down the sub-tasks into 3 estimates and noting how long it would take in each of those scenarios - best case, average case, worst case. Best case: how long you think it would take if everything went right Average case: how long you think it would realistically take Worst case: how long you think it would take if everything went wrong Then a formula is to be applied to the values that would create a bell curve, where the top of the bell curve represented the highest chance of taking X amount of time. The final estimate value I usually went with would be slightly to the right of the top of the bell curve in order to add some buffer room. And it worked out for me pretty well in all honesty.

[@IAmTimCorey]

Thanks for sharing!

[@andergarcia1115]

Thank you , Master, for your advice and for sharing your experience with us.

[@IAmTimCorey]

You are welcome.

[@HollandHiking]

I agree mostly with what you say. I have one additional recommendation. Don't waste a lot of time on estimating projects. It is very expensive and does not work in most cases. So with my team we spent normally 1 hour every two makes to get estimates for the next two weeks. The team also spends a few hours every week on research for things that are coming. The estimates we do are in story points, so relative estimates. These estimates add up to the capacity we have as a team. This works reasonably well, though for individual activities it may turn out very different. At a larger scale, we discuss priorities with the business owners and the we say, well for the next three months, it is like you will get a,b and c. It may be you also get d and e but it is unlikely we have time to d f and g. We sent not more than two hours to make the estimates. Of course you need to know the business you are working for. the other way is that department spent months to collect all wishes, create long lists and then gets stuck in choosing what to do. Keep planning simple and make sure to get trust and communicate, also if things are not working as you expected.

[@IAmTimCorey]

Absolutely. If you can avoid it, do so. Since I own my own business, I do something similar. We don't put timeframes around most things, but rather put priorities on items. Then we discuss the progress we are making and re-evaluate if needed.

[@jaygiles148]

As usual, great advice, thanks Tim

[@IAmTimCorey]

You are welcome.

[@mananagedevanishvili2791]

Best timing as always 😊 Thanks!

[@IAmTimCorey]

You are welcome.

[@keithcourneyea1609]

Same here. Have a bigger project in the estimate phase 😂😊

[@Elemblue2]

I worked at a place that didnt have an estimate system, and I was happy and doing well. Then they implemented an estimate system and within a year I was burned out to the point of being unable to think clearly. I tried to vocalize my issues, and I think they heard me to a degree: That the estimations were based on perfect prior knowledge, no obstacles, thinking explicitly about the critical change that needed to made, and no ramping into the problem. That these estimations would be more accurate if we factored in uncertainty. Unfortunately, communicating with total confidence is a skill requirement for the people that talk to the higher ups, and so that's something everyone found distasteful. Humans are haunted by the "Easier said than done" problem. Everyone loves to say everything is easy. We got rid of the estimates eventually and the situation has improved, but the damage has been done to some degree. I agree with someone of the comments here. Estimations are a tool thats for nothing more than to trick you into devaluing your work and beat you down. Its impossible to take pride in anything you do if your being whipped from behind. I like your solution of picking two of the three. Ill keep that in mind for the future.

[@IAmTimCorey]

Thanks for sharing!

[@olinzknihytovi]

This is great advice for everyone involved in software R&D.

[@IAmTimCorey]

Thanks!

[@moto_matt]

I'm terrible with estimates because I come up with how long i realistically think it'll take me, add a little bit of a buffer, then assume that my boss will think that's too overly cautious and won't like the figure I'm giving him so i take a bit off again, and then my boss usually still isn't happy with the number, so he cuts it down to basically what he thinks it should take, but then guess what, it nearly always takes as long as my original estimate or longer, which leads to lots of unnecessary stress all around! 🤦‍♂️😆

[@IAmTimCorey]

Take that exact story to your boss and have a conversation about it. At the end of the day, the estimate is worthless if it isn't possible. All your boss is doing is coming up with a comforting lie now and avoiding the reality until later.

[@erikharaldsson2416]

The rule of thumb that I have seen somewhere and regularly use, is to take the initial optimistic estimate and multiply by three.

[@IAmTimCorey]

Yep, but that just goes to show how bad estimates really are at identifying reality.

[@andyhudsonsynthpop]

My team no longer does estimates and our workflow sped up and everyone is more relaxed as a result. Estimates are abused by managers to beat you with and to highlight the scale of your failures when your blind guess doesn't pan out. Estimates generally serve no useful purpose whatsoever

[@IAmTimCorey]

Excellent!

[@kylekeenan3485]

The only way to estimate your work accurately is to say how long it took once you finished.

[@IAmTimCorey]

lol

[@Mooseontheloose89]

Always say things will take longer, half the time it’s because you’re given a new problem that no one has investigated 😂😂

[@IAmTimCorey]

Yeah, the unknowns really bite you.

[@krccmsitp2884]

There's only one approach: don't. 😉

[@IAmTimCorey]

If you can get away with that, it is a good approach.

[@PelFox]

Simple, you dont.

[@IAmTimCorey]

lol

[@blackandwhitebharathistory]

Estimate is something that puts a lot of unnecessary stress upon us. Estimation do not work in most of the cases. If we estimate something for 3 story point which is roughly 30 hours then forget boss our own tech lead and architects would start telling us why we don’t need 3 sp and pressure us to reduce it to either 2 or even 1. They are like hey it will just 5 hours why do you estimate 10 hours 🥲