Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: How do you do estimates in 2021?

news.ycombinator.com

Post reply on HN
Print view View original

81–90 of 102 posts

Re: Ask HN: How do you do estimates in 2021?

#81

Post by bsder »

aasasd wrote: post #36
nzmsv wrote: post #15

The below is a joke, but sadly it is representative of most teams I have worked on. If it's like anything that most managers do, you have the team come up with estimates, have some meetings to see if you missed anything, discover that you did, then create a schedule, remembering to add slack time for unforeseen interruptions due to people getting sick, customer issues, etc. Then you see that the schedule is too long.…

As a dev who has quite some freedom managing himself, I learned to multiply my own estimates by about 2-2.5. If I had a bad case of managers, I would probably multiply by four.

3 is about right.

What happens is that the difference between the estimate that management will psychologically accept to begin the project (and then commit to due to sunk cost fallacy) and the actual schedule is about a factor of 3.

Re: Ask HN: How do you do estimates in 2021?

#82

Post by NicoJuicy »

Redsquare wrote: post #73
NicoJuicy wrote: post #23

Has anyone tried Planning Poker? https://www.mountaingoatsoftware.com/agile/planning-poker

Your having a laugh?

I was not aware of any negative sentiment about planning poker/scrum poker.

I was briefly informed about it during a scrum event and didn't saw it mentioned here.

And it's about estimating project tasks. So relevant to the question.

My guess is that you or the down voters don't know it. Correct me if I'm wrong.

Re: Ask HN: How do you do estimates in 2021?

#83

Post by aasasd »

bsder wrote: post #81
aasasd wrote: post #36

Earlier quoted context omitted.

As a dev who has quite some freedom managing himself, I learned to multiply my own estimates by about 2-2.5. If I had a bad case of managers, I would probably multiply by four.

3 is about right. What happens is that the difference between the estimate that management will psychologically accept to begin the project (and then commit to due to sunk cost fallacy) and the actual schedule is about a factor of 3.

You forget to factor in your own bias.

https://pbs.twimg.com/media/EyNRiYQXMAIshEj.jpg

Re: Ask HN: How do you do estimates in 2021?

#84

Post by muzani »

aasasd wrote: post #36
nzmsv wrote: post #15

The below is a joke, but sadly it is representative of most teams I have worked on. If it's like anything that most managers do, you have the team come up with estimates, have some meetings to see if you missed anything, discover that you did, then create a schedule, remembering to add slack time for unforeseen interruptions due to people getting sick, customer issues, etc. Then you see that the schedule is too long.…

As a dev who has quite some freedom managing himself, I learned to multiply my own estimates by about 2-2.5. If I had a bad case of managers, I would probably multiply by four.

There's a paper that gives an exact number: 1.7x. This is the average time it goes over estimates, for code and writing tasks. The other numbers seem better, but you should not go below 1.7.

Re: Ask HN: How do you do estimates in 2021?

#85

Post by chrisrickard »

I've ran a software agency for 8 years, and whats worked best for us is using PERT (Program Evaluation and Review Technique) estimation, or 3-point estimation, where you individually estimate optimistic, pessimistic, and most likely cases - to then calculate a weighted average.

Whilst I've found this can help weed out biases and gut feelings - I still add a multiplier that i've refined over the years. Basically chaos allowance, that aims to take into account the things you can't possible take into account yet.

I think me the most common cause of estimation issues arises more from unclear acceptance criteria, rather than calculation issues, so i've learn to work with my clients to capture a huge level of detail in the user story acceptance criteria (kind of anti-agile I know), and only then do a fine grained estimate for every story. This undoubtedly takes a lot of time, but in the end it's what works well on the majority of my projects (i generally do this in a paid scoping phase).

Re: Ask HN: How do you do estimates in 2021?

#86

Post by poulsbohemian »

nzmsv wrote: post #15

The below is a joke, but sadly it is representative of most teams I have worked on. If it's like anything that most managers do, you have the team come up with estimates, have some meetings to see if you missed anything, discover that you did, then create a schedule, remembering to add slack time for unforeseen interruptions due to people getting sick, customer issues, etc. Then you see that the schedule is too long.…

I think the only thing you missed was that the original estimate also included more FTEs, but then they cut those too. This whole chain of reality was a big part of why I eventually decided I had to get out of tech. The people doing the work can often articulate the work and provide solid estimates to the work, but they will get chewed up by people with other agendas.

Re: Ask HN: How do you do estimates in 2021?

#87

Post by postfacto »

KronisLV wrote: post #61
void_mint wrote: post #52

Earlier quoted context omitted.

> Of course, the above happens when you're in a market that requires estimates as a part of BOMs, which is a lot like bidding on projects and is just a race to the bottom for the most part. Yeah this, to me, totally invalidated the rest of your example. Pick a low number to win the bid, blow the timeline/estimate, require more money to do anything at all. It is not clear to me that any "estimation" changed this calcu…

> Pick a low number to win the bid, blow the timeline/estimate, require more money to do anything at all. Except that there are penalty mechanisms in place to prevent this from happening. So your company was slow to deliver the product and needs more time? You better be prepared to work for your own resources, otherwise the escrow won't get released, as per the contract. Or perhaps you cannot finish it at all? Get re…

Example #4

  A CTO of an American company, to get a bonus of $7 million, lays off a ton-load of the company’s CRM people who knew how 20 years of architecture duct tape that ran the company was strung together.

  CTO then proceeds to hire a cheap, offshoring body shop to design the company’s new website, which talks to the CRM. However, there’s no more CRM people at the American company because they’ve all gotten laid off and the offshore web contractors also now have to become customized CRM experts, which is insane scope creep.

  The outsourcing company can’t deliver and litigation is sought, while the US company takes zero responsibility for the fact that all the CRM people were let go and there’s no chance in hell that web developers at the outsourcing can ever learn the highly customized domain-specific logic that fast that extensively. Meanwhile, CTO gets fired and a severance of $1 million for all the extreme damage he did to the company.
And that’s Hertz vs Accenture, or at least how I heard it to be.

Re: Ask HN: How do you do estimates in 2021?

#88

Post by kthejoker2 »

candiddevmike wrote: post #7

I use Halo difficulty levels: easy, normal, heroic, legendary. They're basically t shirt sizes but I think they better convey the size of work to be done. From there, you haggle around how many you can do in a given sprint, knowing that a legendary one is basically high risk and could take more than one sprint. For level of urgency, I have another system for that, using Cold stone creamery sizes: Gotta have it (must…

Your urgency system is very similar to the MoSCOW method, if anyone's looking for some historical legitimacy for a (very valid) prioritization technique:

https://en.wikipedia.org/wiki/MoSCoW_method

Re: Ask HN: How do you do estimates in 2021?

#89

Post by 1ark »

NicoJuicy wrote: post #23

Has anyone tried Planning Poker? https://www.mountaingoatsoftware.com/agile/planning-poker

Good with 3-6 people who are prepared, ie. what are the designs/requests/requirements. Many times PM thinks its a small feature or vice versa when all engineers give a big/small estimate; they get a reality check, same can be said about backend and frontend. And it is good to discuss different PoV between the numbers. I don't think you necessarily need the poker meeting part if you are able to prepare, discuss, estimate with other means; but if you have team members not able to put the time in for whatever reason it can be good to put some scheduled time in for it.
Post reply on HN