When you work in IT you get used to doing the estimations for the projects, change requests of all kinds, even for the documentation…
Manager: how much time do you need to implement the feature F?
Dev: it’ll take longer to make an estimation than to implement it.
Manager: anyway…
Dev (in a day): it will take 3 hours.
The thing is… it’s horrible. It’s not only the first feeling, it’s actually a detrimental technique, you know? When you ask me about an estimation, you give me some information. Usually something along the lines “we need a tool which should solve the problem X”. At this point I have no idea about the precise need, constraints, obstacles, your behaviour, how many times you’ll change your mind and so on, so even if I had the perfect estimator, it’d have said something like this:
It’s just because there is a bunch of unknowns, it’s as simple as that.
If you give me a detailed specification with a warrant that any changes will void my estimation (you will not give that one, will you?), all I can have is a better estimation (still uncertain anyway):
…but the horrible managers ask about one number.
You know, what I do?
- I take a worst-case scenario and multiply it by an additional coefficient.
You don’t like it? - I take a list of broad assumptions and narrow-down the estimation to a sum of a list of small steps (overestimated, clearly).
You still don’t like it, but you can do nothing about it because each step looks Ok, the math works fine, so you have no choice, but accept it.
You know what? Most of my tasks will be finished waaaay before the deadline because otherwise I’ll be punished. I prefer finishing all my tasks early and help around other people.
My dear manager, you’re still unhappy? Why? I could have done more? Twice or thrice more? Sure, but it’s your fault – you are asking for an impossible estimation and punish your tech guys for being late…
What’s the solution then?
You may think Scrum got it, but… not at all – they ask you to estimate the complexity and turn that into a timescale. Why don’t you measure your time in kilograms (pounds) then?
From the point of view of the tech guy:
- Ask me about a realistic average estimation (like 50% chance of being in time and 50% chance of failing it) and I’ll get rid of my coefficients and rethink the estimation (may or may not divide the previous result by 2).
- Stop changing the specification without changing the deadline.
- Stop specifying the things I can do better. Who’s a techie here?
- Make me talk to the end-users, I’ll understand why we need the project X deployed by April… and I’ll come up with an MVP.
- Stop thinking that adding 2 more devs will help. Actually, it’s kinda like with babies – sometimes you just can’t get them any faster.
- Yep, I’ve forgotten that one:
- 30 minutes-long daily standup with 10 people is actually 5 hours of lost time, you’d better think to adjust the development time (or get rid of that one)
- a 1.5h-long technical point with architects decreases your day by more than 1.5h (because you’ll have to dive into the project again) and if your developer has 3 appointments like that by day, he/she’ll produce strictly nothing
- a short mail or a ticket is at least 30 min off the project (once again switching the contexts)
- A deadline + impossibility to manage correctly your own time are stressful for a tech (actually any) person, so there’ll be a protective barrier in a form of overestimated projects, you see?
So, bug off with your estimations, please. You’re doing it wrong.
TL;DR: your tech guys may be playing Doom on their fridge 50% of the time and it’s the fault of the manager (maybe you) asking for the impossible things. IT sometimes looks like magic, but we are not oracles. Get from your comfort zone and get rid of detrimental habits and you’ll see a performance boost.
Good health to you and your projects.