Hacker News Reader

If it's business the one that wants the estimation, then I take into account everything: unrelated meetings, bugfixing of important stuff that gets broken, potential sickness/holidays, etc. What's the point of telling business that you can do the task in 3 days, if you cannot actually have 3 complete days to do the job? If you have "other work stuff to do" that will interfere between you delivering the item, you have to take that into account.

> Either you're a godlike estimator or you disappoint your manager A LOT. Who the hell are these people that can reliably say feature X will take me 8 weeks? Is that also not just an estimate? I'd rather wallow in the vagueness of points than get my ass reprimanded because I said something would take X weeks. If you're looking for absolute predictability you need factory line work.

You give estimations in time units because that's the only unit business wants. You can sure say "that will take X points"... nobody will listen to you and they will demand a different answer. It doesn't really matter, actually.

I don't think I'm godlike, I've just been contracting for most of 20-something years and I've got good at it. I always give a range. It's never "X weeks" it's "between X and Y weeks" (showing all my workings, too). "X weeks" is always wrong and "X points" is not only meaningless, it also gives no indication of any uncertainty. By giving a range I give the managers enough information to understand the risks - they can choose to go low with their own estimates if they need to win the business, there's no need to pressure the team into giving an artifically low estimate.

I agree that if you start giving a single number of days/weeks, that's bad. Then there's a strong incentive for everyone to start padding their single figure estimates to cover their asses, and the managers end up just halving them in their gantt charts and pushing the team to work quicker. That's an adversarial environment, where nobody trusts each other.

It's more like "the last time I did a case like this it took around 3 weeks to close the case, so 3 weeks this time. Maybe a little less because there's less experimenting.".

Basing it on past experience like that automatically takes into account (average amount of) meetings, waiting on others for code reviews, etc.

>Can you guys genuinely work 2 weeks on a feature without doing anything else?

Sometimes, but you need a progressive team that, e.g. that doesn't do stand ups every day when almost all the work is multi-day efforts.

You also need people who are technically skilled to not bug a developer about something they can find out themselves. More skill = more autonomy = less bother. That holds true for their work too.

A regular occurrence is people around developers leaning on them to figure out technical details because they are not technical enough - that should be their job, so that gap contributes to a higher number of meetings.

>Who the hell are these people that can reliably say feature X will take me 8 weeks?

They're probably overestimating then time the delivery to be around 8 weeks (they are more skilled than their estimate would lead you to believe). A feature like that should get broken up, then you estimate the individual ones. It doesn't matter that the fragments aren't testable/deployable on their own, it helps with the complexity. Decomposing that feature also helps you estimate better.