I find out when they really need it by and tell them they can have it by then. Unless it's impossible, which it almost never is.
The part I like to negotiate is how much focus I'll be given and which are the features that might have to be compromised because they'd add a disproportionate amount of time or complexity relative to their value.
By "focus," I mean that a "month" is meaningless because it might mean that I truly have a full month or it might mean that 3-5 times a week I'll be expected to stop and fix, maintain, or sit in meetings for other projects.
So I'd rather not tell someone that I can do something in a day. Then they expect they can have it in a calendar day, which I can't promise because any given calendar day might be full of interruptions. I'd rather tell them they can have it in a week (unless they need it sooner) and I'll worry about finding which day over the next week is the one that's most likely to be productive.
If they really need it in a day, it's more important that no one bother me for the next 8 business hours than whether the work is "objectively" 7 hours or 8 hours or 9 hours.
For things that really work, see:
- http://www.mountaingoatsoftware.com/books/1-agile-estimating...
- http://www.mountaingoatsoftware.com/articles-estimating
I use these together with mind-mapping and acunote.com to estimate my projects (and it works fairly well).
One of the biggest suggestions that has helped me create more accurate estimates: don't say that a feature/task is going to take N hours. Instead, give it a bounded rank. I use {1, 2, 4, 8, 16}. Total the rank.
That won't be helpful in the beginning, but the real win comes when you've done several projects, and you know how long 40 points will take.
I think most people are poor estimators on unbounded spaces, and this solves that problem.
http://www.exratione.com/2010/12/a-count-and-multiplier-meth...