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

How I estimate work

seangoedecke.com

Post reply on HN
Print view View original

31–40 of 326 posts

Re: How I estimate work

#31

Post by Falimonda »

tuna74 wrote: post #21

Slightly OT, but anyway. The only reasonable way to estimate something is in work hours. Everything else is severely misguided. Also, if you don't follow up any estimate is meaningless.

Work hours is the only way I've learned to think about it productively.

It's also important to gather consensus among the team and understand if/why work hour estimates differ between individuals on the same body of work or tasks. I'd go so far as to say that a majority of project planning, scoping, and derisking can be figured out during an honest discussion about work hour estimates.

Story points are too open to interpretation and have no meaningful grounding besides the latent work hours that need to go into them.

Re: How I estimate work

#32

Post by the_af »

bgribble wrote: post #12

One thing I think is missing is an understanding of why there is such a top-down push for timelines: because saying "we aren't sure when this feature will be delivered" makes sales people look like they don't know what they are talking about. Which.... well. They would much rather confidently repeat a date that is totally unfounded rubbish which will have to be rolled back later, because then they can blame the engin…

I think this is unfair to sales.

I've made your argument before, but realistically, much of the word revolves around timelines and it's unreasonable to expect otherwise.

When will you recover from your injury so you can play the world cup?

When will this product arrive that I need for my child's birthday?

When will my car be repaired, that I need for a trip?

How soon before our competitors can we deliver this feature?

"It'll be done when it's done" is very unsatisfying in a lot or situations, if not downright unacceptable.

Re: How I estimate work

#33

Post by fallinditch »

I find that ballpark estimates are often more accurate than estimates based on work breakdowns ... and this concurs with OP's observation that estimates tend to miss due to the unknowns.

Re: How I estimate work

#34

Post by notjustanymike »

After owning a product, I've developed a lot of sympathy for the people outside of engineering who have to put up with us. Engineers love to push back on estimates, believing that "when it's done" is somehow acceptable for the rest of the business to function. In a functioning org, there are lot of professionals depending on correct estimation to do their job.

For us, an accurate delivery date on a 6 month project was mandatory. CX needed it so they could start onboarding high priority customers. Marketing needed it so they could plan advertising collateral and make promises at conventions. Product needed it to understand what the Q3 roadmap should contain. Sales needed it to close deals. I was fortunate to work in a business where I respected the heads of these departments, which believe it or not, should be the norm.

The challenge wasn't estimation - it's quite doable to break a large project down into a series of sprints (basically a sprint / waterfall hybrid). Delays usually came from unexpected sources, like reacting to a must have interruption or critical bugs. Those you cannot estimate for, but you can collaborate on a solution. Trim features, push date, bring in extra help, or crunch. Whatever the decision, making sure to work with the other departments as colaborators was always beneficial.

Re: How I estimate work

#35

Post by carefulfungi »

genghisjahn wrote: post #13
bgribble wrote: post #12

One thing I think is missing is an understanding of why there is such a top-down push for timelines: because saying "we aren't sure when this feature will be delivered" makes sales people look like they don't know what they are talking about. Which.... well. They would much rather confidently repeat a date that is totally unfounded rubbish which will have to be rolled back later, because then they can blame the engin…

Anyone from a sales roll care to speak to this?

Sales gets fired (or not paid) for missing their estimates (quotas, forecasts) and often have little empathy for engineering being unable to estimate accurately.

Re: How I estimate work

#36

Post by pluralmonad »

xyzzy123 wrote: post #29
bgribble wrote: post #12

One thing I think is missing is an understanding of why there is such a top-down push for timelines: because saying "we aren't sure when this feature will be delivered" makes sales people look like they don't know what they are talking about. Which.... well. They would much rather confidently repeat a date that is totally unfounded rubbish which will have to be rolled back later, because then they can blame the engin…

The top down push for timelines is because: In Australia, an SDE + overhead costs say $1500 / work day, so 4 engineers for a month is about $100k. The money has to be allocated from budgets and planned for etc. Dev effort affects the financial viability and competitiveness of projects. I feel like many employees have a kind of blind spot around this? Like for most other situations, money is a thing to be thought abou…

Doesn't this ignore the glaring difference between a plumbing task and a software task? That is, level of uncertainty and specification. I'm sure there are some, but I can't think of any ambiguous plumbing requirements on the level of what is typical from the median software shop.

Re: How I estimate work

#38

Post by [deleted] »

jawns wrote: post #20

Here's my (somewhat tongue-in-cheek) rubric: - If it's an internal project (like migrating from one vendor to another, with no user impact) then it takes as long as I can convince my boss it is reasonable to take. - If it's a project with user impact (like adding a new feature) then it takes as long as the estimated ROI remains positive. - If it's a project that requires coordination with external parties (like a cli…

[deleted]

Re: How I estimate work

#39

Post by ravloony »

pocketarc wrote: post #18
bgribble wrote: post #12

One thing I think is missing is an understanding of why there is such a top-down push for timelines: because saying "we aren't sure when this feature will be delivered" makes sales people look like they don't know what they are talking about. Which.... well. They would much rather confidently repeat a date that is totally unfounded rubbish which will have to be rolled back later, because then they can blame the engin…

I'm a dev, not a salesperson, but let's be realistic. A company tells you "yeah we're interested in signing at $1M/yr, but we really need this feature, when will you have it by?", to which saying "eh we don't know - it'll be done when it's done" will lead to the company saying "ok well reach out when you have it, we can talk again then" (or just "eh ok then not a good fit sorry bye"), and in the meantime they'll go s…

Just to consider the opposite viewpoint, I sometimes wonder if it's not better that they do churn in that case. Assuming the sales team is doing their job properly, there are other prospects who may not need that feature, and not ramming the feature in under time constraints will lead to a much better product. Eventually, their feature will be built, and it will have taken the time that it needed, so they'll probably churn back anyway, because the product from the vendor they did get to ram their feature in is probably not very good.
Post reply on HN