[huffpopo]

Guess what number they'll accept and double it, put up a fight when they halve it, blame someone else when you miss it, and take the credit when you hit it. At most companies estimates are about control, expectation management, and blame distribution and not about information discovery.

Most people really suck at expectation management, much more than they suck at estimating work.

[MereInterest]

Sounds a lot like the scene in Star Trek: The Next Generation, where Geordi La Forge meets Scotty.

> Lt. Commander Geordi La Forge: Look, Mr. Scott, I'd love to explain everything to you, but the Captain wants this spectrographic analysis done by 1300 hours.

> [La Forge goes back to work; Scotty follows slowly]

> Scotty: Do you mind a little advice? Starfleet captains are like children. They want everything right now and they want it their way. But the secret is to give them only what they need, not what they want.

> Lt. Commander Geordi La Forge: Yeah, well, I told the Captain I'd have this analysis done in an hour.

> Scotty: How long will it really take?

> Lt. Commander Geordi La Forge: An hour!

> Scotty: Oh, you didn't tell him how long it would really take, did ya?

> Lt. Commander Geordi La Forge: Well, of course I did.

> Scotty: Oh, laddie. You've got a lot to learn if you want people to think of you as a miracle worker.

[thaumaturgy]

I always hated that scene, because it fundamentally changed the character of Mr. Scott from engineer to engineering manager. Which, he was, but that wasn't what made his character so compelling to begin with.

LaForge was a competent engineering manager. The writers tended to focus more on the character's people management skills (and, sometimes, terrible personal relationship stuff). He kept things running smoothly. He was smart. You could imagine a detailed maintenance work log for every system on the ship, and there'd be no gaps in it ever since he took the position of chief engineer.

But while Scotty cared about his staff, it was the machinery that he knew inside and out. He never needed to conjure up a hologram of the designer of the warp engines, because he knew them as well as anyone else. His maintenance logs would have gaps because he'd know which things actually needed regular attention, and which ones were just bureaucratic nonsense. He didn't just understand all of it on the technician level, but on the theoretical level too, enabling him to pull off some unlikely saves.

He actually was a miracle worker and maybe one of the best fictional representations of an engineer, and that one scene was written to make him look a little more like a bureaucrat.

[mjevans]

I felt that it was more for comedy as well as helping to develop the difference in character between the two.

LaForge is competent, he's also newer in his overall career. Scotty has been around the block so many times he knows where every crack and seam is.

That was a moment where Scotty's wisdom was being handed down; it's OK to know what it will take, but stuff happens, and there's also the potential to hand tasks off to less senior staff that might not do it at perfect speed. Giving a padded estimate gives you options and room for corrections if there are issues.

[mac01021]

It's actually a comedic reference to an earlier conversation between Scotty and Kirk from the 3rd Star Trek movie.

(https://en.wikiquote.org/wiki/Star_Trek_III:_The_Search_for_...) see the first bit of dialogue in this page.

Also I don't think it makes him seem like a bureaucrat. I'm no manager. I'm an engineer at the bottom of the org chart, but I still need to deliver estimates to my supervisor. And even if I'm an exceptional engineer, I can choose to estimate the time required for a task as though I were merely average.

[huffpopo]

I remember that, made me laugh and wonder; was Scotty really giving it all she's got.

[paulddraper]

In reality, most managers would need it in two hours, but the dev estimates half a hour and then of course it takes an hour.

[gist]

Cliche: "Deliver more than you promise"

[ghaff]

Or "Underpromise, overdeliver."

Sometimes there are legitimate reasons to come up with schedules that are as accurate as you can make them, understanding that stuff almost always happens. Sometimes a project or some dependencies don't make sense if they can't be done by a particular date.

But, yeah, it's good advice in general. For most of the work I do (not programming), I have a pretty good sense of the minimum time I need and I almost always significantly pad that to accommodate priority interrupts or just so I can take a bit of extra time if I feel the task warrants it.

[valuearb]

Never give time estimates.

But if you are forced to give them, never give a single number. Use ranges. Your range for a confident estimate should be roughly 4x between the fastest and longest components. For example, 1 to 4 hours for a task you are very confident about. For things you have less confidence on, your range should be closer to 8X.

Why do this? Because wide ranges are the ONLY accurate software engineering time estimates. You need to communicate the inherent lack of precision in any estimate. For every time estimate you don't know

1) How many hours a day you'll be allowed to actually code, outside of meetings, standup, planning sessions, emergency bug fixes, etc, etc. 2) Which member of your team will actually end up doing it, the fastest one, the slowest one, or someone in between. 3) How many days will be lost to illness or personal issues. 4) How much the actual feature or story will change as it's developed and they realize the design is actual shit. 5) How much other code will need to be changed when you actually rip the lid off some of the older code it will interact with.

etc. etc.

[Too]

A good way to enforce this is to always estimate things in steps of 2^x. Eg you are not allowed to estimate something as taking 20 days, it's either 16 days or 32 days. That way it's obvious that the larger the estimate becomes the more inaccurate it is and you are forced to automatically double to 32 if your "inner" estimate is 17 days.

Scrum has a similar technique only allowing Fibonacci numbers, I think the reasoning behind it is similar.

Obviously the receiver of the estimate should know that you are using this method, otherwise they might start questioning you thinking this estimate should only be 17 for example.

[acbabis]

I once read someone give similar advice about estimation. What stuck with me most is that if someone pressures you to change an estimate, it's no longer an estimate. Most managers don't actually want estimates.

[ghaff]

Many moons ago when I was doing a combination of engineering and project management, I had to come up with a schedule for a shipyard project. Which I dutifully did. It was probably two months or something like that.

Ran it up the flagpole. It got cut in half. Fortunately I didn't need to change the schedule I had drawn up. I just said each box is now half a day. (This was before we used computers for this sort of thing.) As I recall, the job came in very close to my initial estimate.

[taeric]

Don't do point estimates. Pretty much period.

Instead, try actually estimating the work. List components touched. List technologies involved. List screens needed. All of these are measurable. A point estimate is too easy to get wrong and impossible to question.

[valuearb]

Not sure what you mean by point estimates, because point estimates are the only way to accurately gauge the work in a project.

Elaborate work estimations are a fools errand. No one can argue that you can make far more accurate estimates by spending 50% of your time doing research for estimates instead of 2% of your time. But spending 2% of your time on estimates also means you'll finish every project twice as fast.

[taeric]

Point estimate, in this case, is reducing down to a single number. If I'm using the wrong term, please correct me.

Now many people doing this use a "point system" where they escalate the allowed votes as you go up. This is a neat heuristic that accounts for some uncertainty. But it really only boils down the estimates to the easy to estimate tasks. Which are often not worth estimating.

I'm not claiming to be elaborate. But do realize if someone estimates a house project is large, I will have less faith in their estimate compared to someone estimating it will take about 300 square feet of tile, plus for gallons of paint and probably to gallons of mortar.

One shows they have thought and didn't gut shot it. Even better, we have something to actually burn down in the supplies. We can also gauge it with previous jobs to know how long it took to use that much supplies.

Software is tougher, because we don't have the same supplies. But this is why you don't list lines of code, but required screens, technical integrations, and general features. Agreed that you don't want to get too elaborate. But also don't give me some stupid t-shirt sizing or other nonsense.

Not the least of the reasons why, is negotiating a size is dumb. There are literally no reasons not to convince someone they estimated high. However, cutting an integration is a choice that has obvious downsides to account for any speed up in delivery. Even better, it is empowering to choose what you won't deliver, instead of having it chosen for you.

[valuearb]

Ok, then we agree. If you are forced to give an estimate, give a range, and make it a wide range.

When I was referring to "points", I was talking about Agile development. It's planning process is far more accurate than time estimates because it uses points as a measure of the relative work in tasks. It's far easier to accurately say this task is a 3, and this other task is a 5, than to estimate their hours. In Agile planners don't need time estimates because they prioritize tasks based on relative work required (and customer benefit), and the team just works down the priorities until end of it's sprint, and then ships whatever got done.

[taeric]

We marginally agree. I would argue that breaking up between 3, 5, 8, etc. point tasks is a bit of a charade. It isn't that you can compare many tasks of slightly different sizes that is important. Instead, it is knowing all of the tasks necessary.

In particular, those point estimates are not negotiable. Which is why they are less meaningful. Talking someone down from a 5 to a 3 just convinced them to agree they can do a task faster. Presumably at higher risk. Convincing them they don't have to do two of the tasks? That is a clear win, because it is work they don't have to do. Not work they have to try and do faster.

There is also the generative problem of software. As time on a project goes on, changes become slower. So, some task may be a 5 if done now, but a 12 if done later. Similarly, some tasks can piggy back of effort on others, such that they get cheaper in terms of work needed. Though, with time, they probably keep the high time cost.

[valuearb]

Planning poker is not done by negotiating. It's done by doing point estimates simultaneously by the entire engineering team. Providing simultaneous estimates reduces cognitive bias caused by having the lead engineer's estimates influence junior engineers, etc. If they all agree on the point value, no problem. If there is a big difference, then it should open a fruitful discussion so the team can reach consensus. The key is that points don't mean hours, or days or any time measure, it's all a relative measure of the work involved. As long as it is, consensus is usually easy.

All tasks should be pointed in Agile. If anything was left out it's on the team to make sure a story is written for it. For example lets say my PM wants us to estimate 10 stories for the next sprint. If I know I have to do some low level work to update the database to make those 10 stories feasible I'll say we need a story for that, and it needs to be our highest priority since all the other stories are dependent upon it.

But good Agile is done with a Kanban approach, we have a ranked board of tasks, and work on the highest priorities first. If we forgot a task, we add it to the board and point it, and our PMM/PM prioritize it. This can be done at any time in the schedule. When we reach the end of the sprint, we make sure all the completed tasks are done, bug free and we ship.

Then we start a new sprint, working on the remaining tasks, pointing new ones, and working from the top of the Kanban board again.

No one ever need to make a single time estimate, or waste more than a tiny fraction of development time doing any type of estimation.

[honor_roller64]

Triple it and then you have some headroom for when they halve it.

[justherefortart]

I make my best guess and quadruple it. That tends to be the most accurate I get.

I underestimate everything and also forget interruptions, new "on fire" issues, life events (turkey day, etc) and everything else.

So instead of worrying about all the stuff I'm missing, I just give my best guess and say it's that. A guess. If you want to hold me to an estimate, I need weeks of planning to get back to you. In that time I can do the missing BA work, mock up what needs to be done and get a better estimate, which I'll still quadruple.

[ghaff]

An engineering manager I used to work with would drive me crazy. He had this "methodology" he referred to as a 90% schedule but it was a 90% confidence schedule only in the sense of no one ever getting sick for a couple of days, tests not failing, no hardware being defective, etc. etc. It won't come as a surprise that this schedule was basically never met.

[patrickmay]

Double it and go to the next higher units. 4 hours? That's 8 days.

[paulie_a]

Exactly. Never give a be range either. The lowest number is now your estimate.

[jwatte]

It's only about control in the sense that it matters what a business invests in. If I believe that feature X will be worth $Y, whether I invest in that, or some other feature, depends a whole lot on how much I expect to pay to get X. Opportunity cost is the important metric here, not just absolute RoI.

[mratzloff]

I'll share another perspective.

Execs view it as being able to make informed decisions about where to spend the company's time and money.

Let's say you have projects A and B you want to do, and you've estimated revenues from each at $11 MM and $4 MM. You really want to do A, since it would establish a business relationship with a new strategic partner, but estimates come back that A will take 16 weeks and B will take 4 weeks. You only have time to focus on one project at a time, so you choose B to try to capture a quick turnaround before moving onto A. Plus it would make an existing partner happy.

Execs know from experience that the engineering estimates usually suck. Sometimes they're really high and sometimes they're really low. Execs decide as long as B doesn't exceed 5 weeks, we're OK. They don't communicate this down the chain because if everyone knows 5 weeks is the "real" number they'll (grudgingly) accept, they are pretty sure someone somewhere in the chain will spend a week optimizing the test harness or refactoring the build process or something.

At week 3, engineering says they're gonna need 2 more weeks. Execs: Sure.

At week 4, engineering says they're gonna need 2 more weeks again. Execs are annoyed but now the work is mostly done, and everyone promises on their children's lives it will actually be done in 6 weeks, so they let it finish.

At week 5, we're still on track for week 6. Execs: Sure.

At week 6, we're gonna need another week. Execs: Whatever. At this point they've abandoned all faith in this engineering team. They re-task some other critical part of the business with beginning work on project A. Some part of the business suffers.

B actually takes 7 weeks when all is said and done. Execs wouldn't have bothered with it if they knew that up front. Everyone involved in B takes a reputation hit: the product manager, the project manager, the engineering manager, and the engineers themselves. The people who blame others get an even bigger reputation hit.

Now there's pressure from some sides of the exec table to make up time on project A and get the estimate below 16 weeks from a team that had nothing to do with B.

Happily for everyone but the first team, it turns out the other team is able to get project A out the door in just 12 weeks. Everyone on the first team takes another reputation hit.

You might say that the root problem was the estimate for B was too low. That is a problem, but the fact that the estimate for A was 25% is equally problematic. Had either estimate been more accurate, the company would have focuses on A first.

All of these execs are accountable to the CEO, who's accountable to the board. The CPO or CTO or whoever are not escaping unscathed from this, because at the next board meeting the CEO has to answer for why project A was delayed into Q2.

[valuearb]

We are just finishing a long refactor that strongly improved the product. But the planning process was poorly done. They took a couple of lead engineers, made them draw a bunch of diagrams we didn't need, and made them estimate all the work time, instead of involving the entire team. And all of the commitments in the schedule were not commmunicated to the entire team till the end.

From the exec's standpoint, it looks like we can't be trusted. But the truth is the process can't be trusted. Never give out time estimates. Use Agile and point planning, and relative cost estimates.

In your example, the team should have said that we estimate A is 4x as much work as B. Pick one, we'll get it done as fast as possible.

You can have a fixed time schedule, or a fixed project feature set. You can't have both, without the project being late, and features being compromised.

[mratzloff]

You described two problems.

You identified the first one correctly: they had the lead engineers estimate in isolation and not involve the team in any way until the end. Beyond being a bad way to estimate, it's a bad way to manage a team.

But then you said you should never provide a real estimate. That conclusion doesn't really follow. The leadership team has to come up with real estimates. "A is 4x as much work as B" is good information, but it's pretty useless when it comes to actual calendar planning.

The second issue, and the larger one, is that long, stop-the-world refactors (or rewrites) are the fastest way for the engineering team to lose all credibility in my experience. The business keeps moving even if new feature development doesn't. I've found incremental refactors to be the best way to go. And those are much easier to estimate.

As far as schedule vs. feature set, if you estimate properly and prioritize all of the least-needed features at the end, if you find yourself falling behind you just pop those tasks off. But you build that contingency in and communicate it up front.

[valuearb]

You contradict yourself st the end. If the organization can accept lower value features being deferred at the end, you never need a time estimate. Just a finish date.

In our case bogging down the entire team in time estimates would have wasted even more time and we would have accomplished even less. Had we kept to an agile process with sprints we could have met the fixed schedule expected, and delivered more benefits given that losing our leads in planning for weeks on end meant they contributed relatively little to the refactor.

[mratzloff]

Wow! If your planning is taking weeks, something has gone seriously wrong.

What I said was no contradiction. How does one arrive at the finish date? Finger in the air? There are essential features and nice-to-haves, and to get a delivery date you need to estimate them. But it's an estimate and so you plan for contingencies.

[valuearb]

Yes, something went seriously wrong. When it became clear we had no idea how much longer it would take (because the app wasn't in a fully testable state so our bug counts were meaningless), we got asked to spend half a day re-estimating task and bug times. Which was time not spent fixing bugs or making the product testable, or even making the schedule predictable, because fixing blocker bugs for testing was the only way to do it.

At the end they required twice a day reporting meetings, the standup to say what you were doing, and an end of day status meeting to say what you did so it could be communicated to the exacs. Two more meetings where zero development gets done.

I am not really disagreeing with you. It's reasonable to do basic estimation in most projects. Usually marketing/management need to know when something can ship in order to plan the launch plan. So you figure out how long you need to be really confident the essentials will be finished, and use the nice-to-haves as padding that can be deferred if necessary to make the date.

But if you don't have to hit a specific date, say the product is already shipping and just needs regular constant improvement, just do it in fixed schedule sprints. Focus on the highest priorities every sprint, get as many done as possible during it, ship the new release, rinse and repeat. A well run sprint can be great because eschewing time estimates means more time spent actually building the product.

[roel_v]

What is the core argument you're making here? I mean sure, I too can argue any point by making up examples about abstract projects A and B, but I'm not seeing what fundamental dynamic you're trying to illustrate here.

[mratzloff]

There's no argument; as I said, I'm sharing a perspective. Most engineers, and you can see it in the comments here, approach estimation as an us vs. them battle of wills. The perception battle that they deal with on a regular basis isn't going to improve that way.

[madengr]

PM always wants ROMs (Rough Order of Magnitude estimates), then they bitch when actual project cost is under 5%, or head will roll if it's 1 penny over. Not understanding an order of magnitude, much less a rough one, is why they are not in engineering. They don't like it when I say a ROM is roughly accurate to 0.1X to 10X cost.