11–20 of 121 posts
* set an estimate, you'll deliver in 1.5x your estimate * don't set an estimate, you're losing total control over delivery (rarely for the better, even though that may happen)
In other words, estimates are not a tool of delivery planning, but of risk management : they are here to help limit time dilation.
imo, the problem with estimates vs reality is that estimates don't include mental state. And just to clarify more about mental state, I am referring to being in the zone / flow, and individuals are healthy and experience normal stress / happiness levels. We assume and expect consistent productivity from ourselves. Anecdotally, In my 20 yrs experience, I've never heard a software engineer saying to their manager "add…
In other words, if you are not getting fired and the company isn't folding, and that neither is happening anytime soon, then everything is just "business as usual" and missing a deadline here and there is just part of the natural statistical fluctuations that everyone have come to accept according to some unwritten rules.
I would go as far as drawing parallels between "being in the zone" for a software engineer and "meeting sales targets" for a salesperson. In that sense, not being in the zone every now and then is just as reasonable (or unreasonable, depending on your employer) as missing sales targets every now and then.
Each 3 week Sprint we deliver what the team commits itself to.
However on a macro level we fail spectacularly. Initial Roadmap estimation of how long new features take are way off. A new feature should be ready in 3 sprints.. make that 6. This milestone should be reached in 2 sprints.. Make that 4.
It often comes down to hidden requirements that are discovered midway or prototypes that get into feedback loops with stake holders and take much longer then expected. Compared to those problems, we Rather seldomly we hit unexpected technical problems that prolong a project (but of course this happens too)
Estimates are here to fail, but they're nonetheless crucial: * set an estimate, you'll deliver in 1.5x your estimate * don't set an estimate, you're losing total control over delivery (rarely for the better, even though that may happen) In other words, estimates are not a tool of delivery planning, but of risk management : they are here to help limit time dilation.
"Plans will always fail but we must always have plans."
Do you:
a) Tell your boss that you effectively suck and it will take you 4 weeks instead of 2?
b) Tell your boss it will take two weeks and then blame delays when the deadline passes?
or
c) Tell your boss it will take two weeks, then cut corners to deliver a finished project in two weeks, but one that is so lacking that someone (possibly not you) will need at least 4 more weeks undoing and fixing stuff at a later stage?
(Note: I have NEVER seen anyone do 'a'. It's usually a creative hybrid between a and b)
> So, what did we learn? 1. If you are coding or writing, multiply the expected time of any specific task by ∼ 1.5x (the real completion time will now probably still be 1.5x longer than your new expected time, but you tried). 1.5x matches my real-world SW dev experience.
Example: 1 day == 2 weeks, 1 week = 2 months, 1 month = 2 years. More than a month = Let’s not even start.
An important thing I've learnt is that people over-estimate what they can do in a short time whereas they under-estimate what they can do in a long time. You probably wont finish that feature tonight, and that's OK. But you will have built something good in a year if you work on it a little bit consistently.
Honest question. Say you have a project. Your boss expects it can be done in two weeks. Let's say you are good at estimating your own velocity, and you estimate four weeks for that project. Do you: a) Tell your boss that you effectively suck and it will take you 4 weeks instead of 2? b) Tell your boss it will take two weeks and then blame delays when the deadline passes? or c) Tell your boss it will take two weeks, t…
So, you've never seen someone being a professional ? I've told my boss plenty of times his estimates are wrong, and that it will take longer. It's my job to know how long things take. If my boss thinks it can be done shorter, he better 1/ have the same work experience that I do and 2/ do it on his own.
Honest question. Say you have a project. Your boss expects it can be done in two weeks. Let's say you are good at estimating your own velocity, and you estimate four weeks for that project. Do you: a) Tell your boss that you effectively suck and it will take you 4 weeks instead of 2? b) Tell your boss it will take two weeks and then blame delays when the deadline passes? or c) Tell your boss it will take two weeks, t…
Honest question. Say you have a project. Your boss expects it can be done in two weeks. Let's say you are good at estimating your own velocity, and you estimate four weeks for that project. Do you: a) Tell your boss that you effectively suck and it will take you 4 weeks instead of 2? b) Tell your boss it will take two weeks and then blame delays when the deadline passes? or c) Tell your boss it will take two weeks, t…
Isn't that how it's supposed to be?