"No, it's less effort than that"

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?

>Is there anything I could be doing better here?

Yes. Not give a fuck about the code debt and quality, and just rush out something that barely works. That will keep them satisfied.

I have found success with having a session with the PM where the goal is not to have complete, perfect cards, but at least one ticket for every thing you can think you will need to do on the project.

So you’ll have a bunch of one liner cards, but at smaller fidelity, like

- Make a bulk create API endpoint - Migrate data from old to new table

Then, if there are 5 or more cards there, make your estimate

((number_of_cards / number_of_devs) * est_business_days_per_card) + est_pto_days

It will not be accurate - but it will leave the PM and their boss feeling like the estimate was thought out and reasonable at the time, and any necessary delays will go over easier (“we estimated assuming every card was about the same number of days, but these two cards were large outliers that took longer than expected.”)

Much like the normal sprint process, but without the need to keep a track of sprint velocity beyond a gut feel.

Having built a few of these and inherited a few, please don't. They become brittle and future changes become increasingly difficult, until velocity grinds to a halt. Then you're just firefighting constantly.

My guess is there is a happy medium between never changing and staying on the cutting edge. A place where you can ride the current of tech, FOSS, dev communities and talent pools.

If course what this looks like day to day and in pointing poker will vary. Ideally there is a seasoned architect on every team who can steer the biggest decisions away from the hazards.

This is the problem I have at the moment as well:

Company Leadership asks for estimate with barely any information, I will then say that I need to learn more about the project and look into the codebase, leadership then says that they "just" need to have an estimate to approve this work and if they want to do this project at all. Around and around it goes until I give them a large estimate (which is large because of all the unknowns including the unknown scope) which is then too much and too expensive for leadership.

The goal is to leave the company before this becomes your problem. ;)

I say this as the person who gets hired to fix things after they left.

Reminds me of the time an estimator asked me how much it costs “to program a PLC.” I asked what the PLC had to do and they said “just a normal one.” Pretty sure I answered “probably between $5 and $100k.”

I was interviewing a CISO for a prior job. We asked how they would expand our team, given what we have and what we do. The candidate said that a typical team needs X, Y, and Z, but they really couldn't make an informed decision like that without being in the environment for at least a few months and seeing the way that things actually work.

My peers and I, who would report directly to the CISO, loved the answer. One of the CISO's potential peers on the interview panel thought that the candidate bombed the question, because "shouldn't they just know what's needed?"

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.