[jon.kiparsky]

Working on making a sane build/development process happen at my workplace, I got an interesting comment from one of my co-workers:

Quote

This is why I don't like to give estimates

There's some real truth in this link - we do tend to underestimate bug time, and these are some real reasons why this happens. However, good time estimates are very useful to the people requesting changes - after all, they only have so many hours to "spend" and they do a much better job of budgeting those hours if they had an idea of the cost for each feature or fix. It gives them a sense of perspective.

So I'm curious how other folks handle time estimates? Are issues estimated on the way in? Does anyone log the actual time, for calibration? Does it seem to help? What seems to work?
(yes, I'm fishing here, any useful experience would be appreciated)

[no2pencil]

I usually measure my turn around time to the client of 'proof of concept'/'working product'. Then I offer an amount of time for 'troubleshooting' the product, & this is based on the size of the project. Could be days or weeks for this step. Then the amount of input from this step will alter the turn around time of the final product. Because this is the step that usually includes scope creep, it also has the potential to alter price as well as turn around. Once price gets altered, the customer usually backs off the scope creep & puts it back on schedule.

Quick example, say I offer a fully functional website to a client in 4 weeks based on the development contract. The first 2 maybe 2 & half weeks will yield a working product, another five to seven days will be spent testing in real usage by myself & the client, & the final week will be devoted to changes/updates. If the client decides they missed something they want included or alter that is beyond the scope of the design by contract, the inclusions get added to the contract with a new price & new turn around time.

[mojo666]

We tend to have a good idea how long projects will take, but we always exagerate the time expectation to the user. That way, we look awsome when we show them the product a couple of days early, even though we actually finished it the day they requested it.

[Nykc]

We tend to use points - since when we switched over to the agile process giving timed estimates (eg. dev estimates 13 hours and QA estimate is 4) would usually translate to 17 hours according to the business side.

With points, it is based off of velocity and usually the higher the number the more complex the story is.

[baavgai]

I'm a full time employee, so my estimates aren't given in billable hours but work days. I've done billable hours; it's a slightly different mentality

I strongly believe in the Scotty principal. I guess how much I honestly believe it will take, under ideal conditions. I then double or triple or more that number based on a guess of potential pitfalls.

When I explain this to colleagues, they're often aghast, "you mean you lie?!?" No, on the contrary, by estimating much higher than you actually believe before real work is done, you tend to more closely approximate reality as Murphy kicks in. If you get the work done in your ideal time, that's great, no harm no foul. If, more likely, you end up hustling to reach what once seemed like an inflated estimate, you still haven't disappointed anyone.

I once had a boss who enjoyed frequent status meetings and insisted on project completion percentages. I dealt with this using what I thought of as the half life principal. Projects would hit 50% real fast, then 75% more slowly, once you hit the 90s, percent complete could go into fractions...

[fromTheSprawl]

I usually avoid making estimates like the plague because I'm almost always sure that my estimate would get shot down. I usually give 1.5x of what I think it would take me, but now I'm intrigued by this Scotty Principle. Guess I need to watch the original Star Trek dvd I bought now.(Only watched the first episode).

[jon.kiparsky]

I think the "Scotty Principle" or something like it is required for reasonable estimation, but the multiplier chosen will depend on the person doing the estimation.
The claim is, if you take someone's (maybe even your own) history of estimations and you compare it to the actual time taken, you'll probably find that there's a pattern. Most people are optimistic to some degree, and this (in theory) would allow you to determine roughly how optimistic they are.

What's the granularity of your estimates? Do you estimate a project as a whole, or you do break it into pieces and estimate those?
The agile model would have you estimating in pretty small chunks, if I understand it correctly. This makes sense to me twice. First, because it forces some honesty and some design into the estimate. The more your estimate is based on actal design, the more accurate it's likely to be. Second, because it gives the client a better sense of what their design changes will cost them. (thinking still in terms of hours - dollar cost is a derived number)

On the other hand, most of the thinking about time estimates here seems to be at the project level. Is this just for the sake of simplicity? That is, does a whole-project estimate conceal a detailed breakdown, or are you really estimating a project from nose to tail as one number?

Since I'm now officially in a death march, I've become very interested in the factors that got me there, and what steps might have kept us out of the morass. I'm pretty convinced that the lack of useful milestones, caused by the lack of useful estimates, is a big factor, so I'm interested in how you all handle this.

[baavgai]

LOL, you know, I pulled "The Scotty Principal" from memory, thought I'd made up the term. A quick google shows I'm not alone.

From the Original Star Trek. Scotty, when posed the question of how long it would take, might responded "Ah, Captain, I can not have it for you in less the 12 hours."

"You have two."

"Noooo! You don't understand. It's just not possible!"

"I need it NOW!"

"Aye, Captain."

And it's done in one hour.

This little passion play happens enough in Star Trek that it's one of the stock gags. Like the very short life span of the guy in the red shirt. Or McCoy saying something like, "Damn it, Jim! I'm a Doctor, not a Cheerleader!"

[jon.kiparsky]

I had no idea whether you made it up or picked it up along the way, but I knew exactly what you meant. The weird thing is, I've watched about two episodes of Star Trek in my life.

[baavgai]

Osmosis. There are some things that are just part of cultural consciousness, whether you like it or not.

I don't pay attention to sports. I'm rather happy when I make it to a Super Bowl without even knowing who's playing. I'm happier when I miss such rituals entirely, but they always seem to assert themselves, assault you from the hive mind despite protests.

[fromTheSprawl]

Turns out what I read from Google is from Star Trek: The Next Generation:

Quote

As usual there is sort of problem that needs solving and Geordi La Forge has an idea of how to fix it, and tells the captain it will take 2 or 3 hours. When Geordi and Scotty get back to Engineering, Scotty asks Geordi, "How long will it really take you?" Geordi says, "2 or 3 hours."

Scotty's response is shock and he says "You told him how long it would actually take you? How do you expect to be considered a Miracle worker if you tell them how long it will really take."

link

They get the estimates from me for the negotiation and business part of the project. I think I should really kick my habit of waiting for them to give me the time frame to work on something, and try estimating things on my own.

Also, I estimate the whole thing, not piece by piece. Another bad thing that I need to remove. I hope more schools teach their students to do proper estimations, because giving the wrong one could be fatal.