Pretty much correct, IMO. Really, the first build (and usually the only one, unfortunately) IS the process of estimating. I try to POC as much as possible to make sure I know where the landmines are. Just this week, I blew by one of my own recent estimates because I assumed I could pretty easily determine the output column names and data types for any arbitrary SQL Server stored procedure using a SQL query. Many implementation hours and attempts later, I realized my folly, and I am not new to SQL.

Did you look at sp_describe_first_result_set?

https://learn.microsoft.com/en-us/sql/relational-databases/s...

> Really, the first build IS the process of estimating.

You hit the nail on the head.

yes this

difficult to scope some projects without starting the build

I have found a sure way to get estimates... Do the work, and say how long it took me.

You should probably still add a week to the estimate.

It's realism, not cynicism. I've absolutely been in situations like that where the sensible estimate is 5X what management is angling for and I know it's the case because we've done that exact thing (In this case, new hardware bring up) many times and with the inevitable problems, it always takes the high number. :/

I worked at a place where everything had to be gold plated. Some devs had an idea for a json driven form. It was super simple. Less than a week of dev time. Management got it and an architect got involved. The project was taken from the original devs. The new team spent 2 months building a DSL, that didn't support mobile (so didn't meet the requirements). In the end it was canned.

The original 3 man dev team (Rails/JS/IOS) did a bit of skunk works, and built the original idea in 2 days. We had a good head of tech at the time so we deployed it and just kept quiet when we estimated new forms.

It is possible to give shockingly correct estimates, but management doesn't like to hear how long it'll actually take, they just want to hear the number they already imagined.

How so? Genuinely curious.

Just an intuition developed over time with experience I suppose, as long as you have a fixed team you've worked with for a while on similar projects, with requirements that don't depend on many external factors.

The only consistently accurate estimates are based on previous work for which you have data. As a general rule, if you did X and it took Y days, the next time you do something similar to X, it will take an amount of time very similar to Y.

The problem is that (a) most organizations don't track and record the time to do anything and (b) people don't want to take the time to break down tasks to units similar to something they did before. Estimation is itself a time-consuming task.

Agree, splitting up tasks and writing all out to a T and then estimating it, could take basically all time or budget available for project.

Doesn't take anywhere near that long, but if you want accuracy, then you have to put in the work.

The easiest way is through ridiculous padding. If you consider carefully and think it will take a day, say it will take two weeks. If two weeks, say six months and so on.

This is the sort of thing you do when the unthinkable outcome shifts from idle workers to late delivery: Today, it's unthinkable to management for workers to be idle. If instead it were unthinkable for the project to be late, they would have to accept some risk of idleness to create that outcome.

Of course, you can always start doing prep work to de-risk the project, such as spikes, POCs, et cetera, within the planning phase. This might allow you to pad less but retain the certainty of your outcome.

I worked at one place where if the estimate for any task was over 2 days it would not get approved. Some really required two days tasks could take months. If we didn't want to do it, high estimate. If the business really wanted it they asked different devs until it was two days. Such a strange place to work.

Was the intention to force people to break tasks down into smaller chunks? There's no way you're spending months on something that can't be broken down at all.

Breaking projects down into <2 day chunks isn't a bad idea (although max 2 days is a bit aggressive), but those chunks are likely going to be useless to stakeholders and shouldn't be communicated outside of the team.

If you are fully in charge of a project you can often create complete specs. When working with PMs, designers, other stakeholders, you can often not have complete specs because the requirements are constantly shifting. Because you're "lean" and "agile".

I don’t see this working out. Mostly people want something working right away and writing out specs would eat out all dev budget - you could create complete specs if you pay with your own money, maybe?