Monthly Archives: May 2014
I recently had a heated argument with a couple of our developers. They were creating a new module in one of our systems, and were building the UI based on a screenshot from a designer.
Developer: “Here is what was auto-deployed to the development server last night. As you can see it is a somewhat working prototype.”
Me (After picking on several aspects of the design): “..so I guess we’re pretty far away from anything I can show the customer.”
Developer (groans): “As you can see, it’s perfect and doesn’t need any tweaks..”
Me: “Well, were you looking for feedback, or did you just want me to compliment you on your CSS skills?”
Developer: “I was after feedback, but I am allowed to be grumpy when I get it. So, if we change the stuff you mentioned, can we move on to the admin part after that?”
Me: “If we present it like this, we’ll be thrown under the bus. I need it to be as close to the design screenshot as possible. Now that I’m looking at it again, I’m actually worried even that won’t be good enough.”
Developer: “Seriously?! Well, God. I need a timeout. Give me two minutes to grab another coffee..”
After a lengthy discussion while looking at some state of the art, jaw dropping design templates online, we all realize that we haven’t been aiming high enough with the new design. I’ve been giving them a hard time for maybe thirty minutes, even though I know their job isn’t easy. We’re hard pressed for time, and I know I’ve said the functionality is more important. But I also know that the current design simply won’t cut it. I try to calm things down.
Me: “I know I’m being harsh here, but I needed to get the message across.”
Developer: “So, if we don’t even think the design from the designer is good enough, why do we spend time implementing it? I don’t even want to do it anymore after seeing how much better it can be done.”
Me (pointing at one of the crazy designs we checked out online): “I hear you, but can we even do anything remotely like that?”
Developer (looking straight at me): “We can do anything!”
“Most people fail in life not because they aim too high and miss,
but because they aim too low and hit.”
(This is part #2 in my mini series of blog posts about estimates. Part #1 can be found here)
With the help of detailed analysis, an experienced developer may figure out the most likely outcome of a project. But exactly HOW likely is the most likely outcome?
In the previous post we were forced to guess the duration of a project, and ended up guessing the project would take 300 hours. As a side note, the result after detailed analysis will probably be quite close to the same number. This is known as anchoring. In order to keep each post relatively short, we will save that for another post.
Let’s assume you’re given time to do a detailed analysis of the proposed project, consider the risk and are provided with a “complete specification”. You spend maybe half a day thinking about it, jot down some detailed estimates, and add them all together. The total sum is 290 hours, and you figure that to be the most likely outcome of the project. Your assumption may be exactly wrong for any number of reasons, but for the sake of argument, let’s assume you’re actually correct.
You have now figured out that the project will most likely take around 290 hours. But exactly HOW likely is it that the estimate matches the actual end result? 60%? 80%? You may be surprised to learn that the actual number is probably quite a bit lower than that.
Above illustration represents the actual outcome of 42 Norwegian projects from several different companies. (Magne Jørgensen / scienta.no)
Let’s say you have historical data from several past projects, telling you both your estimated, most likely outcome, as well as the actual outcome. If you put them in a graph with the x-axis representing the actual effort in percent of the estimated effort, and the y-axis representing the percentage of the total number of projects, it would probably look something like the graph above. Confused yet? Let me explain that again.
The highest bar in the above graph is the one marked “100” on the x-axis, and the value of that bar is around 33. That means that roughly 33% of the projects were completed on the estimated time. Since it’s the highest bar, being on time appears to be the most likely outcome. The next bar to the right, marked “125” on the x-axis, indicates that a little over 15% of the projects actually spent 125% of the estimated time, and so on.
So why do you care? Because it sheds light on what “most likely” really means. And it may not be what you think. Actually, our most likely outcome (hitting the estimate spot on) is NOT very likely to happen. Yes, it surely is more likely than any other individual result, but it is LESS likely to happen than all the other results combined. We actually have a whopping 67% likelyhood of NOT hitting our estimate, even though (due to some unknown miracle) our estimate is the most likely result of all possible results.
To make matters worse, the combined likelyhood of the bars to the LEFT of the 100% bar (representing actual outcomes that were lower than our estimate) is only about 7%. So we got 33% likelyhood of hitting our estimate, and 7% likelyhood of being below.
If you provide your boss with your “most likely” estimate, you will in this example leave him with a 60% chance of blowing the customers budget.
I’ll leave you with some time to think that through. Part #3 of this mini series can be found here.
I know a whole bunch of developers in different companies and different businesses. What they all love most about their jobs, is when they are asked to produce an estimate. It’s the highlight of their week!
You’ve had a creative discussion with your boss and perhaps a couple of representatives from the customer. It’s all fun and games, until your boss turns to you and asks The Question.
“So, how long does it take?”
Did he just do that? In front of the customer, no less? How on earth are you supposed to answer that reliably without any time to analyse the details? You venture a somewhat vague answer, even though you know it’s no use.
“Hm, perhaps somewhere between 200 and 400 hours?”
“What does that mean, between 200 and 400 hours? Just give me a number!”
“Oh, uhm, I guess around 300 then?” you reply desperately, automatically reaching for the average of the first two numbers you threw out there. Surely that can’t be too much off?
Any one number representing a possible future outcome of something, will never be anything except just that. One possible outcome. That means somewhere out there, you’ve got a whole bunch of other possible outcomes as well. So If you say it might take 200 hours, without the backing of additional data, the chance of it taking more or less is about 50% either way.
So you’re giving your boss a definite number based on your guess on the outcome of something, without any information about other just as likely outcomes. Does that sound like a useful number to you? I didn’t think so.
Estimates are usually needed to figure out wether to invest in something, and to set a budget. If you give me a number where it’s a 50% chance of me blowing my budget, then I’d say you’re not really helping me over here. It’s heads or tails wether I’m in trouble with the customer for overspending. So when I ask for an estimate, it’s implied that I need a number that isn’t very likely to be too low.
So if your boss (or your customer) insists on getting that one number, what to do? First we need to understand more about the problem of “just give me a number”. More on that in part #2 on this mini-series about estimating!