> How do you do this?

Give half-order-of-magnitude estimates as confidence intervals. Avoid using "hours" or "days" as estimates. Story points work really well here.

Be extra clear on priorities and burndowns to make it clear that you're not just blowing them off. Give short but frequent demos (not just reports) of progress. If later they're concerned about progress, you can point back to all the times you reviewed the product, touched base about priorities, and agreed on next steps.

Make risk really clear to them. If the project is 'get it done in three months or bust', then the payoff (ten times the principal?) better be high enough to account for the risk (30%? 50%? 70%) that you won't make it on time and on budget. That is, you don't want to wait until failure to discover a bad business plan.

At the end of the day, you need to be willing to be patient with and/or walk away from 'business people' that can't wrap their heads around the fact that 20% profit on a venture with a 50% failure rate is a bad business plan. Making employees stressed or overworked to compensate is not a humane solution to the problem. To that end, don't work crazy hours to meet a deadline. That is bad for you, bad for your team, and bad for management since it enables dysfunctional planning.

> Give half-order-of-magnitude estimates

My current boss likes to ask "is it a day, a week, a month, or a year" and while sometimes I just want to say "yes, it's one of those" I actually think that's a pretty reasonable way to ask the question.

I heard a saying once, "Deadlines slip by the units they're measured in." If you say three weeks, it will slip by weeks, not days or months. If the estimate is months, etc.

Could you go more into detail how these story points would work. It seems like in the end a story point would always be associated with a number of days (or hours).

I measure effort, complexity, risk, and dependencies all with one number. If you don't

Things that affect story point values for me. Note that some are more about quantifying "risk" than "how long will it take?".

- how "big" is the change?

- how many parts will be changed?

- are the exit criteria vague or open to interpretation?

- is the change easy to test?

- do we have sample inputs and outputs?

- will we have to design for a tricky deployment?

- will we have to design for a tricky rollback?

- will it be hard to peer review?

- if this feature is impossible or more expensive than we thought, will we know early or late?

- is any of the code being changed extra finicky?

- do I need lots of help? code from other teams? approvals? new software installed? new hardware?

- can I iterate on this code? or does it really need to be perfect the first time?

- will we have developer 'concurrency' or 'parallelism' issues? can anyone chip in and help whenever? or is one distracted expert the only one that can do this?

...for me it's an intuitive guess at a number that flattens all that into something we can use to prioritize work and decide that work needs to be broken down more. What exactly is on that list will vary, certainly, but I would put on anything that could cause bugs, make you wait, or make you underestimate a task.

I'll often say something like "I don't know off the top of my head, but if you want I can get back to you with an estimate."

Once it's clear that I'm going to spend some non-trivial amount of time working on the estimate, the answer is often, "No, don't bother."

On the other hand, if person asking does want me to get back to them, I now have the time to do a good estimate—research the problem, break down the parts of the solution, think about the unknowns. Even a "good" estimate is still squishy, but it does tend to be based on explicit assumptions, and often flushes out hidden design or spec issues.

Spend time to fully estimate each task in each feature point in hours and double it of course. Now increase the unit of time by one: 3 hours = 6 days, 2 days = 4 weeks, 4 weeks = 8 months.

I have a rule. If I trust the PM, I always give my best estimation and a level of confidence on this estimation with the risks. Like:

- I think it will take a week, but this part looks a bit complex, so we may have delays.

- Or, I did something similar last month, so I am quite sure that will take 3 days.

A good PM will know how to deal with this information and what to expect.

If I don't trust the PM, I just add massive paddings.

As a PM, of course, I know this padding is happening and generally will add my own:

You know in your mind it will take you 3 days

You give me, your PM, an estimate of 2 weeks

I report up the chain that it will take a month

When it's all said and done, you end up getting it done in a month by the skin of your teeth :-)

But my point is that if there is a relation of trust between the PM and the developers, padding is unnecessary.

I had PMs to who I could give optimistic estimations and risks. That way, the PM could plan the different scenarios (like extra features in case we had spare time).

Other PMs, the ones who converted estimations into deadlines, got lots of padding. And the problem of adding padding is that it is time lost, because a developer who adds padding cannot tell that they finished earlier.

> How do you do this?

I draw them the Cone of Uncertainty (http://www.construx.com/Thought_Leadership/Books/The_Cone_of...).

Often times managers demand an estimate from you, not because they need the job urgently done, but just so that they can hold you accountable to something. If you promise something, they can assume that you will give your best to keep that deadline.

One way to do this is to point out how the requirements are vague, lack context and fail to state how the requirement will benefit the business. Point out how it is sloppiness in documenting requirements that leads to scope creep, cost overruns and ultimately, failure of the business. Tell management that if they really want to give developers responsibility for finding out what is needed then they should fire all the business analysts, project managers and product managers that are not doing their jobs properly.

Alternatively, they could accept new processes that make sure requirements are clearly written and include acceptance criteria.

The idea behind estimates is to get you to think about the scope the work that is to be done. Quickly walk yourself through the process, give a SWAG, do your best to track your time spent on the task, then review what you got right and wrong in your estimate. It's less about giving the exact time required (in theory - some managers will never understand that) and more about estimating if you have time to complete X, Y and Z.

SWAG means what in your example?

Silly Wild Ass Guess

In most places "I don't know" doesn't have much effect. Just means the estimate comes from somewhere else. Another developer, or a PM.

People are just trying to make decisions about spending money, keeping clients informed, etc.

There are some research and moon shot type exceptions. But, for the most part, estimates are a necessary evil.