Live data from Hacker News

Hacks for Engineering Estimates

shubhro.com

11–20 of 41 posts

Re: Hacks for Engineering Estimates

#11
My go-to heuristic is three point estimation, basically a weighted average of the best, worst, and average case [0].

(Best + Worst + 4 * Average) / 6

One nice property is that it imposes a distribution that adjusts for longer tailed risks.

https://en.wikipedia.org/wiki/Three-point_estimation

Re: Hacks for Engineering Estimates

#12
post #9

Things, IMO, which are spoilers: 1. Starting with an End date and create a plan from there. Some top leads want to get promoted and want to achieve X by this quarter or next. 2. With so many people leaving, there is not enough time and resources to onboard new folks, who are accounted in deliveries 3. Too many parallel initiatives 4. Unstable production taking daily attention 5. Not able to priortise tech debts over…

I just finished a big project and those indeed were big spoilers. But also:

7. Difficulty in getting clearer specs when it's discovered the original specs are not detailed enough.

8. Decision makers at top (or middle?) having too much grass root visibility and micromanaging the project.

Re: Hacks for Engineering Estimates

#13

When I make an estimate, I just double what I think it is and this is usual pretty accurate. I keep underestimating, sometimes doubling down I wonder myself, will it really take this long? 99% of the time, in the end, the answer was yes. So this is my goto method. People still think I finish stuff quick, even if I think myself it's too long.

My favorite estimation hack / joke is similar: take your best estimate, double it, and move up to the next higher time units.

So "oh, an hour or so" becomes 2 days. A week turns into two months.

I don't usually express those estimates, but it gives a good check on an initial, usually optimistic guess.

Re: Hacks for Engineering Estimates

#14
post #2

Interesting article. Our PO often almost demands estimations from us. Usually I am already responding in a best/worst case fashion. In the end PO only seems to remember the best case and takes it as commitment. Since I was fooled by this a few times, I am now collecting a paper trail and am quiet reluctant, when giving "just a ballpark figure". My key takeaway was, that estimations mostly aren't about accuracy or get…

Agreed. I'm much less liberal with my estimates with external stakeholders than I am with close associates, purely for political reasons. If I say 8 weeks to my team, I'll say 11 to management/others. I get no benefit out of delivering on time, a little for delivery early, and a massive loss by delivering late, so I have 0 incentive to give them an "early" estimate. Under promise and over delivery is corporate strategy 101.

Re: Hacks for Engineering Estimates

#15

When I make an estimate, I just double what I think it is and this is usual pretty accurate. I keep underestimating, sometimes doubling down I wonder myself, will it really take this long? 99% of the time, in the end, the answer was yes. So this is my goto method. People still think I finish stuff quick, even if I think myself it's too long.

My favorite estimation hack / joke is similar: take your best estimate, double it, and move up to the next higher time units. So "oh, an hour or so" becomes 2 days. A week turns into two months. I don't usually express those estimates, but it gives a good check on an initial, usually optimistic guess.

I like your method. A 1h task usually is done in two days after the start anyway due to like testing or reviews or what ever.

The main feuture is that you can report more work than there are hours of work. E.g. complete 8 days of work in two days by doing 4 2-day tasks.

I find it way easier to estimate when something is done rather than how much time it will take to do.

Re: Hacks for Engineering Estimates

#17

I think the biggest thing holding engineering estimates back is that the people asking for them are actually not interested in accurate estimates; instead they are looking for inputs to be used in various games of corporate politics.

Yeah. I am going through this right now. And they have no interest in increasing productivity. Instead of looking at slow processes that can be improved, management wants to add more process to get "better" estimates. These estimates will fall apart quickly because of constant scope changes. It's really infuriating. I understand that there is a need for budgeting and stuff but I also know the only way to get things done is by doing them. No amount of estimation helps if your processes are inefficient.

Re: Hacks for Engineering Estimates

#20

I think the biggest thing holding engineering estimates back is that the people asking for them are actually not interested in accurate estimates; instead they are looking for inputs to be used in various games of corporate politics.

"Project Management Theater"
Post reply on HN