Try this experiment: Blindfold yourself, put your hands flat out and ask someone to place one 5gr cookie in your left hand and two 5gr cookies in your right hand (on top of each other, so you can't feel how many there are by touch). Now there's 10gr of weight on your right hand and 5gr on your left. Can you tell which is heavier? Science tells us you shouldn't have a problem telling apart 10gr from 5gr.Now do the same with a package of cookies. Put a 100gr package in each hand, after removing one cookie from one of them. The weight difference between them is still 5gr - but it's going to be much harder for you to say which is heavier. Sensing the difference between 100gr and 95gr is much harder than between 10gr and 5gr.
Lastly, if you try it with 200gr and 195gr, you should no longer be able to tell them apart.
Our perception works largely on a logarithmic scale. It's not just true for weight, but also for loudness of sound, brightness of vision and other kinds of perception (distance, taste and more). The "bigger" things are, the more difference between them it takes for us to be able to tell them apart, a phenomenon described by the Weber-Fecher law and Stevens' power law.
So what does all this have to do with project management? I'd argue that this quirk of perception and estimation applies to estimating tasks in a project as well. We're usually quite good at estimating whether a task is going to take one or two days, but estimating whether a task is going to take 30 or 31 days is nearly impossible.
That's why we at Gigantt think t-shirt sized task estimates are a very good idea for projects. It makes little difference if a day-long task actually takes 8 or 9 hours, so you may as well avoid talking about hours in such cases and just say one day. Similarly, if a much bigger task is going to take 20 or 23 days there's no real difference and you're unlikely to be able to nail that estimation so accurately, anyway. So just say it's going to take one (work) month.
(Of course, you shouldn't be estimating anything in such large chunks. The right thing to do is break 20-day tasks into smaller pieces and estimate them individually, in the process also realizing how much unexpected work actually goes into them, and thus getting much more reliable aggregate estimates.)
The Weber-Fechner point of all this is to avoid comparing things of similar magnitude. Those are too hard to tell apart. If you limit yourself to t-shirt sized estimates, like [1 hour, 5 hours, 1 day, 3 days, 1 week, 2 weeks, 1 month, etc.] you're going to round off a lot of estimation errors and make your life much easier. It also makes life easier within the organization. You won't need to haggle over whether something should take 9 or 10 days - just call it 2 weeks and move on. Everybody can agree on whether something is going to take one or two weeks. Your under- and over-estimations will even out.
I think the reason we're such poor estimators has something to do with our logarithmic perception. If you're listening to music at 50db and someone increases the volume to 60db it feels like a 20% increase in magnitude, but it's really a 10x increase (1000%). Decibels are a logarithmic scale, and that's similar to how our hearing works when it comes to stimuli of different magnitudes. That's why Decibels are such a useful scale to us. I'm saying we need a similar scale for estimating work. We need work-decibels. When faced with estimating a new task - something you haven't done before - a lot of the times you would try to look back at something similar and say "well, this looks like 20% more work" and a lot of the times you're going to be dead wrong. You're just not that good at comparing things of similar scale.
3 comments:
Great article Assaf. I am a big believer that having 2 estimation numbers: a min and max value makes way more sense than having a single value. For example a recent estimation I made is 2-4h. This still has the same order of magnitude (logarithmically) but gives a better understanding of what might go wrong and right.
The problem with that is that at the end of the day it's not that useful for decision making. I've used systems in the past that gave you best/worst estimations. I've also used systems that gave you a whole range options - a probability distribution of delivery/date. But a manager still needs to make a decision - are we committing to delivering this feature - yes or no? And when it comes time to answer that question he/she need to pick a number - 50%, 75%, 90% - what sort of confidence do you choose? I've seen projects that went passed their 100% estimates. So aside from it not being that useful, and more of a "let's cover our asses by saying, hey, you were told the worst-case estimate..." kind of feature, this approach also works under a very wrong mathematical assumption - that project lateness is actually distributed using a normal distribution (i.e. a bell curve). They don't. Otherwise you wouldn't see so many projects take 3x the time/cost. So the whole idea of adding one more 95% estimate is already DOA. Now, if you're saying the worst-case estimate is going to be not a 95% but a truly exponential doomsday estimate (like 3x the effort) then we're back to usability. What would a manager do with this information but ignore it?
This is why we don't offer estimation ranges, velocity or anything like evidence-based-scheduling. These are promises that fail to deliver. There's no substitute for actually doing the work - that is, breaking the plan further and further down to smaller pieces, updating it as frequently as possible with new information, clearly marking and estimating your unknowns and prioritizing them, etc. It's more work, but it yields a better, less speculative outcome. I'm going to blog about this topic, too, btw - about why velocity and such don't work.
I agree with Sveder having two numbers does help sometime but it can also lead to confusion and over complication so I don't advise it for every project
Post a Comment