From The Pragmatic Programmer: From Journeyman to Master:
What to Say When Asked for an Estimate
You say “I’ll get back to you.”
You almost always get better results if you slow the process down and spend some time going through the steps we describe in this section. Estimates given at the coffee machine will (like the coffee) come back to haunt you.
In the section, the authors recommend the following process:
- Determine the accuracy that you need. Based on the duration, you can quote the estimate in different precision. Saying “5 to 6 months” is different than saying “150 days”. If you slip a little into the 7th month, you’re still pretty accurate. But if you slip into the 180th or 210th day, not so much.
- Make sure you understand what is being asked. Determine the scope of the problem.
- Model the system. A model might be a mental model, diagrams, or existing data records. Decompose this model and build estimates from the components. Assign values and error ranges (+/-) to each value.
- Calculate the estimate based on your model.
- Track your estimates. Record information about the problem you are estimating, your estimate, and the actual values.
- Other things to include in your estimate are developing and documenting requirements or changes to requirements specifications, creating or updating design documents and specifications, testing (unit, integration, and acceptance), creating or updating user’s manuals or READMEs with the changes. If 2 or more people working together, there’s overhead of communication (phone calls, emails, meetings) and merging source code. If it’s a long task, account for things like other work, time off (holidays, vacation, sick time), meetings, and other overhead tasks when picking a delivery date.
Software estimation is the most difficult single task in software engineering- a close second being requirements elicitation.
There are a lot of tactics for creating them, all based on getting good requirements first. But when your back’s against the wall and they refuse to give you better details, Fake It:
- Take a good look at the requirements you have.
- Make assumptions to fill in the gaps based on your best guess of what they want
- Write down all your assumptions
- Make them sit down, read, and agree to your assumptions (or, if you’re lucky, get them to give in and give you real requirements).
- Now you have detailed requirements that you can estimate from.
It’s like my mother used to threaten when I was a kid “Hurry up and pick out some clothes, or I’ll pick them out for you!”
I did development for a guy who was very adamant about wanting accurate estimates. What we settled on, which worked very well, was this:
- I billed for all the time I spent estimating. It came to around 20-25% of what I billed.
- I did extremely detailed examination of the tasks. No shooting from the hip. I went into the code, figured out what lines needed to be changed, what other parts of the program it would affect, how much testing I’d have to do to ensure that things still worked. I’d estimate each piece in units of .1 hours (6 minutes).
- I sent him my estimate for each task along with that detailed breakdown.
20-25% of billing sounds like a lot.
But he’d ask me to make change XYZ, thinking it’d take about 2 hours. In 1 hour of detailed estimating, I’d determine it’d take 8.5 hours. So he’d decide whether it was worth 8.5 hours of pay. If not, then he saved 7.5 hours over what it would’ve cost him if I’d done it without an estimate.
And if he did want to invest the 8.5 hours, the detail work I did for the estimate was work I’d have had to do anyway.
I found that with this method I was able to bring most tasks in on time or even early, without having to heavily overestimate. Because the time was broken down so minutely, I could tell early on if I was slipping. If I hit roadblocks so that after 3 hours I could tell that my 8.5-hour task was going to take 12, I could talk to him about it before more time passed so he could reevaluate and yank the feature if he was concerned about the cost.
Was he nickel-and-diming? No, I looked at it as letting him apply his money where he saw the most benefit. And I was glad to get experience in estimating, which I’d always been terrible at.