I don't bother with any work that takes less than 2-3 days myself. The overhead of managing the work, communicating and understanding the requirements, context switching and getting up to speed with the code base etc makes the overhead / coding ratio pretty high and as a techie I'd rather be cutting code.

What are your thoughts on Planning Poker ( http://en.wikipedia.org/wiki/Planning_poker) and possibly other estimate tools?

Yeh they will always be just 'estimates' after all but then maybe some other tasks will turn out to take more time than estimated. You can usually mitigate over or under estimating somewhat, by breaking down tasks that appear to be large at first.

Also just wondering y you are paying to have estimates done rather than doing them your self? is it a time constraint thing?

It's normal when you're trying to get someone to do a 3 hour contract for you. Especially when it's a new contractor without a working knowledge of your code. His estimate could be something like 10 hours of coding + several hours for meetings and talking + few hours for acceptance tests and change requests due to specification being incomplete/unclear/misunderstood + some bug fixing = about 20-30 hours of work. For such small projects it's better to batch them in a bigger release and work with someone who already knows the product so the overhead will be smaller.

Ayende: Did they break down the estimate into sub tasks? 32 hours is too big for one task -- that suggests they didn't have much confidence, or the task wasn't clearly defined and weren't sure of the gravity of the changes required. (Where you sound like you had a much better idea what was needed yourself).

If you can get a reasonable hourly rate with someone you trust and respect, you are much better off doing T&M than fixed bid, as then you don't have to pay for the padding.

However, from my experience in consulting, customers never want T&M, they want to know how much something will cost.

If you are their customer, they shouldn't share with you any estimations. They should let you know a price/cost and the delivery date, anything else.

Maybe they were adding "found two odd bugs, debugging, re-testing" to this time estimate? That would account for the increase in time, but I guess one big bug per feature is enough, and that would be maybe 8-10 hours total estimate.

Ruben

+1 Rafal:

I recently went to get quotes from carpenters to replace an exterior door. (new lock, etc.) Both showed up and said it was a fairly simple job, about 1-2 hours, I even got an hourly rate out of one of them at $45/hr. But when I got the quote they were both around $500 + materials. Obviously their justification was a half-day minimum charge. I'd have been happy enough if they'd said it was a small job, charge me for the 2 hours, but I'd wait until they had an otherwise unfilled opening or finished another job early enough to pop-by. (They were both based within 5 minutes of where I lived.)

I put up the door myself in about 4 hours.

Could I be over simplifying things by suggesting that the estimate was 32 hrs because that is what the developers thought you would pay them?

The biggest problem I see in estimating is that people love to work in "day" chunks. Something simple becomes half a day, something a little harder becomes a day, and anything beyond one and a half days only increases in day increments. This is the way most people are wired due to the fact that most companies really only care about when something is due, not how long it took to do the work.

When something takes "a day", I guarantee that a developer doesn't work on it for 8 hrs. In fact, they probably don't even do more than 2 hrs of actual work, the rest is emailing, reading blogs (like this one), going to meetings to talk about something that they already know the answer too, filling out timecards/timeshsets, checking fantasy football, and about another 4 hrs of crap that I can't even put in here since this sentence is already too long.

If something reasonably complex needs to be done by the end of the week and you assign it on a Monday, then miraculously the estimate comes in at 4 days. It's almost a self fulfilling prophesy.

Steve, a full-time worker gets paid the same amount of money, no matter if there's actual work to be done or not or how effectively he's doing his job. Contractor has no such luxury, he must keep his orders coming in order to get some money. And he must have money also for the time when he's busy running his business and doing all the things that don't count as real work for the customers. Of course he can set his hourly rate higher so that it pays also for the unpaid work, but this would put him instantly out of business because the rate wouldn't be competitive. So there's no choice but to add some overhead to the work estimate, especially when the orders are small and irregular. And I think that's ok and normal (provided that the overhead isn't too excessive).

Rafal,

I've been a contractor, so I understand how it works. But It's not Ayende's (or any clients) responsibility to make sure a contractor is bringing in the orders, it's the consultants job.

Apparently this contractor has set 32 hrs as their minimum, which Ayende found too high for his liking. I agree that it's okay for a contractor to add a bit of a premium to their rate (otherwise, why do it?), but in this case it appears to have been excessive for the scope of work. Ayende even said he would have accepted 14 hrs, which is over 400% overhead, so the developer STILL would have made a good ROI, plus they would have gained good will (with the possibility of future contracts as the reward).

Anytime I see an estimate that is divisible by eight, chances are the developer didn't take the act of estimating seriously, that or they are rolling in a heck of a lot of things into their estimate. For a contractor who is billing hourly to estimate in 8 hr blocks, I feel that's even worse.

8-14 hours would have probably been fair, but don't assume it is 400% because you are comparing a subject matter expert (Oren) with someone with argueably less experience with the project.

It may be they are overly pessimistic in their estimating. If that's the case the question would be if they estimated 32 hours, and actually finished it in 14 hours, how much would the bill be? I know there is a lot of temptation to self-reward for a job done quicker than agreed. Why not? If they're happy, you're happy, but it comes down to personal ethics.

I don't recall the name of the billing model, but when I did freelance small I.T. stuff I normally provided 2 rates. A billable rate which I estimated at, and an @cost rate to cover any unexpected surprises. So in the aboved case if I felt comfortable that I could get the feature done in 8 hours it would be an estimate of 8x billable rate, and if anything unexpected came up and it needed to go longer that would be provided @cost. It splits the cost of risk. The client pays for risk, but I don't profit from it. (I'd much rather be using the time for billable work.) The major challenge is to ward off scope creep, but this just meant getting requirements down to distinct features..

It seems that not much people here really worked with or as contractors.

When we are doing estimations at work, we usually ask the dev how long he thinks that it will take him to do a task, he will quote a certain time, on this, we do * 4 because of the overhead, the possibility to get a bug, to get this, or that which will delay a little the work, you can add this and that, unit test, component test, tracing the requirement, writing some documents, if you add a process like CMMI, it will be more even paper work etc. In the end, a 2 hours developing task, can easily 10 h of actual work. Beside this, not much people will do a 1 day task. In each company I have been, they won't bid on projects under the 18 man months ( for ex 3 men * 6 months ) unless it is about improvement over a current contracts.

You all may be interested by Dave Laribee's recent piece on estimation:

http://laribee.com/yestimation

His system has 0,1, or 2 point stories. 1 point stories roughly equate to a day's work. This is completely different from everything Agile I've heard. Though I trust his experience, it's certainly not common wisdom.

@Set

That's sub-contracting, and a completely different barrel of fish. It doesn't apply to smaller, agile projects where features are implemented as individual units of work. He certainly isn't about to approach companies like Fujitsu to implement features like sorting.

Case in point, something that does come to mind: Ayende, Given your earlier example of vague requirements, perhaps some of the "fat" added to their estimate was time needed to extract requirements out of the picture in your head.

I will recognize that I don't have a strong knowledge on agile development, but I cannot believe than anyone starting a project and be clueless on things to do or switch providers midway if the previous ones were doing their job, especially on a few hours task.

If this is agile, then it is insanity.

Nah, it's called "still getting stuff done when you don't have or need 18 man-months and $6M". :)

I think it can be either of 4 things :

1) They were not interested in doing 3-4 hour job and hence quoted you high as a way of politely turning you down

2) They didn't put time and effort into going deep into the task at hand and gave you just a shallow estimate (based on figure they would like to earn!).

3) They deliberately try to overcharge you, knowing that you are busy and you probably won't have much choice.

4) They were new and didn't understand the code-base at all.

Single number estimates are far less useful than a range of best to worst case scenarios. Maybe the contractor thought he could do the job in half a day, but it could take as much as 4 days (if any major bugs came up, there were some unclear requirements, he wasn't familiar with the codebase, etc). The single number of 32 hours doesn't indicate if this is the best or worst case scenario and it doesn't indicate the level of confidence that the developer has in the assignment.