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:

1. Take a good look at the requirements you have.
2. Make assumptions to fill in the gaps based on your best guess of what they want
3. Write down all your assumptions
4. 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).
5. 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.

It depends on what the estimate is for.

For an initial, high-level estimate for a business case then the key things are:

1. Speed. Whatever method you use it needs to be quick. The whole point is the stakeholders aren't sure if it is even worth doing the project - which is why they need the numbers for the business case. If the business case was solid they wouldn't need your estimates. The bulk of these projects won't go ahead so it is important that too much effort isn't expended providing the estimate.
2. Give a range. Make it broad. You have had no time to analyse requirements, workshop with stakeholders, validate assumptions. A wide range tells the recipient of the estimate "Software projects are naturally complex and risky - if you want a proper estimate you need to give me more details and more time". The problem with giving a single number or a narrow range is that it paints you into a corner by setting expectations before any real analysis is done.

I find the best technique to pick a comparable project that "feels" the same. "Feel" is completely subjective - but with this kind of estimate my experience tells me you won't find objective measurements. Then provide a wide range. I've read some books that say a range of -50% to +100% is good but it depends on many factors.

For a detailed, low-level estimate:

1. You need a baseline. If the baseline isn't stable the estimate is meaningless.
2. Bottom up is best. Get a detailed work breakdown, estimate each component then roll it up into a larger number. I find planning poker to be a great technique here.
3. Document contingency. Make it clear where any contingency (if any) is added. Is it added to each line item? Or to the whole estimate? Or to specific risks? Or is there none?
4. State your assumptions. Validate as many as possible given the time frame.
5. State explicitly what is included and excluded in the estimate. For example, is review included? Are technical delays included?

We're often asked for an "ballpark estimate" during meetings where we're given very broad and vauge ideas of what they'd like to do. I always say, "if you want an answer today it's a year and a million dollars. If you'd like to give me a lot more details and some time to review them then I can refine those numbers for you."

They almost always get the point.

"Two weeks!"

Seriously. My first estimate is always two weeks. Because I have some sort of bizarre mental block that makes me think everything sounds like it'll two weeks.

I try to work around it, try to really think about how long I think something will take, trying to identify all the potential trouble spots and bits that look too black-box-y for me to be accurately estimating. And try to recognize that if my answer is "Two weeks!", I've likely failed to do so.

Pretty much every good manager I've had has learned to recognize "Two weeks!" as an answer that requires a mild verbal pimp-slap in response.

Some advice from the dark side from one who learned the hard way.

The requirements are unclear. Nobody has done an in depth analysis of all the implications.

Don't do an estimate at this point. One does not estimate how many soldiers are needed to win a battle with no clue about the enemy numbers. The estimate is made after scouting. This is unless you already fought this enemy.

The new feature will probably break some assumptions you made in your code and you start thinking immediately of all the things you might have to refactor.

This is your responsibility to factor in unless you expect others to have the expertise about this area.

You have other things to do from past assignments and you will have to come up with an estimate that takes that other work into account.

Same as above, even for unanticipated work that's created by a slob team mate next to you with a near non-existent test procedure which causes your code to glitch out that you can't perfectly predict in advance. It's a weather forecast.

The 'done' definition is probably unclear: When will it be done? 'Done' as in just finished coding it, or 'done' as in "the users are using it"?

Understand the user-end requirement here, think like a user. Don't do what your peers do if they estimate something to be "done" just because some basic functionality with a barebones workflow that no user can possibly tolerate is what they consider to be "done". Think of it from the user standpoint, because that's all the client you're making the estimate for will typically understand. Estimate towards the complete user-end requirements, not towards the barebone technical requirements. And realize that your clients asking for estimates will be totally inaccurate here about how they word things and understand the technical aspects of what you say.

No matter how conscious you are of all these things, sometimes your "programmer's pride" makes you give/accept shorter times than you originally suppose it might take. Specially when you feel the pressure of deadlines and management expectations.

Don't do this! You sound like a self-motivated hard worker and possibly one who gives in easily to coercion.

The problem here is this: let's say you and Joe made time estimates for the same task (but between two separate employees, unaware of both estimates at one time). You estimate valiantly, "one week". It's okay you think, you'll work over 100+ hours a week, unpaid overtime. Now you're three days late.

Meanwhile, Joe estimates 5 months. You think this is ridiculous, you think you can pull this off in one week. How much does Joe work? 10 hours a week? ... except he finishes on time in exactly 5 months.

Guess who gets perceived as the jackass? That's right, you. Joe seems like a great worker, you seem unreliable now. It doesn't matter so much that you might have achieved an even better result in ~7% of the time that Joe took. What matters is that you were 3 days off from a one week estimate.

Never err on the side of the tighter estimate. Err on the side of the looser estimate. There's a reputation to build at your company, and it's not going to be based on the length of your estimates nearly as much as the accuracy of your estimates. It's easy to be accurate with an estimate that's too long, you just get more time to work on the problem and solve it better. An estimate that's too short leaves no breathing room at all, you either meet it desperately or you're screwed.

It depends on the organization and how the estimates are used.

If the estimate is just to provide a general idea on when it will be ready, I can generally do a quick estimate based on my experience. Often times I will include any uncertainty or possible variations with the estimate along with how the changes may impact other areas of the system and the extent of regression testing required.

If the estimate is used for anything contractual or in a scenario where more precise timing is required, I do a full work break down. This is more work and requires more in depth thinking about the design and changes to the system, but is much more accurate, especially for larger pieces of work.

In either case, on-going communication is key. If you do run into something unexpected, make it known at the time instead of waiting until the deadline. If the requirements are not-clear, make sure you document your understanding of them and the functionality that you plan to deliver. This is also helpful with any assumptions you make. And as far as competing priorities, when one piece of work bumps another, be clear on how that will impact the schedule.

Confidently. I can't tell you how many times I botched up an initial meeting with a client by not putting on professionalism when giving an estimate. Even if you're blowing numbers out of thin air - make sure you always keep some estimate around. That said, be careful not to estimate yourself into a hole. Different things take different amount amounts of time, effort and resources to put together. Here's a good way to do it:

Them: How much will it cost?

Me: It depends on what you want me to do. Generally, I start this sort of project at around $X.

First, if some task was assigned to me I would break it down into subtasks.I would estimate the time for each subtasks and probably with subtasks I would be able to find the problematic area and hence I would be able to forecast how long it would take to a certain extent.

But still all the planning would help only to a certain extent. Only when you start coding you can find the exact issues

I always end up giving estimates that I later realize I cannot fulfill. It has happened countless of times, and I always promise it won't happen again.

It sounds like you're being asked for a commitment, not an estimate. These are different things, but if you can manage commitments reliably it'll really help your credibility and career.

Some advice based on my ~10 years of experience:

• Always provide a range (i.e. lower and upper bound). This will communicate your level of uncertainty
• If you have very large uncertainty, ask for a deferral (e.g. 1 day to do analysis, and then provide a tighter range)
• If the task it too large, break it up and provide a range for each piece

A bit late but when I was in the military we were instructed to use PERT to determine estimates. It does require some experience in your field and the task at hand. It was surprisingly accurate when determining estimated time of completion when maintaining and repairing electronic devices (complex radios and satellite comms equipment), where any number of things can be wrong or found and needed to be fix during routine maintenance. The estimations were important because other units may be inoperable until they received back their comms equipment. One that I've used is this Free Online PERT Calculator