The problem I have with task breakdowns is you get way too much engineer overconfidence - i.e. there is literally no task which is less then an entire day's effort, in practice. There's about 6 usable hours in a day - I've watched people confidently bid they'll get something done in "half a day" but when you point out that's about 3 hours, suddenly they're way less sure about that number - or offended. Then 3 days later they're still working on it.
Sometimes it is not overconfidence but a side-effect of management interference & second-guessing the estimates.
In this case engineers give an estimate of what they think management wants to hear and not the actual time it takes. It happens if they are frequently asked to reduce their estimated time to within management expectations.
To deal with this, you need to bargain with them in the opposite direction to make sure the estimates are realistic.
Managers are typically squeezed between the person who "wants the project done, and sets the budget" and the technical folk doing the work.
Kinds like the architect sitting between the client and the building contractor. The client wants the moon, on a low budget, and wants it completed yesterday.
A strong manager understands their role, and the constraints (time, money) of the system and is able to find compromise where necessary. They're there to guide the owner, and at the same time monitor the workers.
Of course the vast majority of middle management are not strong. They see their role as passing on orders from on high. The boss is the customer, and the customer is always right. So their only part is to demand more from the workers.
Strong tech workers understand what the manager needs. Good time estimates. Limited budget. The manager needs to be passing accurate data upstream. Bad workers ignore reality, tell a manager what he wants to hear, and just do their thing. Not realising that they (the programmers) will be the ones thrown under the bus ehen it goes tits up. (Another sign of bad managers is to blame the underlings.)
Good managers, working with good techies, is a match made in heaven. Together they deliver accurate estimates, with plenty of contingency time. Together they decide what features are necessary, and what can be canned. If you are in this dynamic, count yourself lucky.
If you are a good manager working with crap staff, well, that's unlucky. But at least you can turn them over. If you are a good tech working with a crap manager (which I suspect is most of us) then, well, I guess the only options are to stay, or quit.
Bad managers can be made better with explanations though. The more they understand the constraints, the better equipped they are to argue the point with the customer.
this, the number of times I've heard: I can't sleep those estimates to the customer. How is that a me problem? I don't care how you sell it, just know that my estimate is pretty accurate on how much time we need to build it.
And also don't expect us to work 8 hours a day doing tasks.
Estimating time for a task is it's own skill. And, of course, the danger is in the task being insufficiently specified, leading to unknowns.
Cook lunch, estimate 30 minutes. Task starts, oh wait, cupboard is bare, need to go shopping.
Over a long career I've found that you do the best estimate you can with the information provided. Then multiply by 4. Sounds extreme, but you're still likely to be short a bit.
Equally, for estimates, I like to first estimate the number of data tables. That's a good factor to bring in to the rest. A system with 10 tables, 100 tables, 200 tables and so on "magnifies" the task list.
"Build reports" has a proportionate number. 10 tables might mean 5 reports. 100 tables might mean 50.
Building reports might be easy, but the number of them means time is needed.
This is close to my rule - whatever I think, multiply by 3. Then multiply by 3 if it includes any amount of "get another team, under a different manager, to do something". It's been accurate more times then I care to think.
> Over a long career I've found that you do the best estimate you can with the information provided. Then multiply by 4. Sounds extreme, but you're still likely to be short a bit.
Me myself rely on Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
But sometimes I see a task that would take about a day... and then people insist on breaking it down in four parts!
Then they take about a quarter day each, provided the same person does all four simultaneously. Or about a day each if you give them to different people.
