Most people really suck at expectation management, much more than they suck at estimating work.
> 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.
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.
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.
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.
(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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
My main concern here is precisely that it is not negotiated. I like the idea of making sure folks are on the same page. However, the idea of another meeting to discuss what we should instead be building is nauseating.
Instead, meetings that decide what we are not going to build are much more productive feeling. Which is why they should be negotiations. If there is just a list of tasks that has to be done, just keep the list up to date and let the team work on them. If there is concern on priority, make a choice and let the team weigh in. Don't add to their work by asking them to prioritize on behalf of stakeholders.
And kanban is good, but really needs handoff spots between teams. Otherwise, you are just in a constant swarm. Often rewarding the fastest workers. Which is fine, but risks alienating the slower ones that could contribute in other circumstances.
My viewpoint is let marketing estimate the value of features, my job is to give them a rough estimate of how hard each one is to build, and they can decide priorities based on those two things, and tell me what to work on first. If I go too fast and lesser developers feel left out, I'm happy to pair program and do code reviews with them to help them improve.
Yea, all my projects have to have a defined release process (code freeze, final bug fixing/deferall, final acceptance tests), you can't kanban your way through that, but you can kanban your way to it.
And I should be very clear, if what you are doing is working for you, that is by far the most important thing. I am decidedly not trying to convince you to stop and change.
Further, If it can be formulated and shared with others, I'd be interested in the results. However, I have come to find that I do not expect things to generalize between people nearly as often as my instincts would want them to.
I do take this as a challenge to how I've viewed stuff. Currently, I'm on leave for about a month, but when I get back I plan on paying more attention to the process. I'm hoping I don't miss any retrospectives on projects that were finishing up as I took leave. I'm not convinced people typically zero in on the important points. I am still fully convinced you should always try.
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.
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.
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.
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.
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.
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.
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.