←back to thread

388 points replyifuagree | 1 comments | | HN request time: 0.201s | source
Show context
dbalatero ◴[] No.37966573[source]
I think the biggest challenge I have is that people will immediately ask for estimates when the project is barely a paragraph description. On top of that, my feeling is always "it depends on how much tech debt is in the code after I look in there."

The only reasonable response I've had is "I need 1-2 days to both push you on solidifying these requirements, and stop & audit the codebase to look for any risks before starting".

Is there anything I could be doing better here?

replies(4): >>37966655 #>>37966663 #>>37967031 #>>37972226 #
1. gen220 ◴[] No.37972226[source]
You’re doing the right thing, but you need to speak their language.

In Agile speak, that’s a 3 point spike ticket, for which the deliverable is a detailed set of requirements and deliverables with estimates with considered trade-offs. It’s a totally normal thing to do.

You can give an estimate before doing the spike, but maximally caveat it. Like “60% confidence it’ll take fewer than 3 weeks, 80% 5 weeks, 90% 6”.

I’d generally recommend refusing to give deadline estimates beyond a week or two (unless it’s absolutely necessary as it sometimes is), preferring piecemeal estimates (i.e. this project is composed of 7 deliverables each taking 1-2 days of work). Reason is that it might take 10 days of engineering work to do something, but due to shifting priorities etc., the calculus of computing a deadline is basically pointless.

If the “managers” don’t understand any of this, it’s never going to be peaceful unfortunately.