* Split work as small as possible, and atomic so that aborting/undoing is possible if required. Like all teams we do throw away a lot of stuff. * If a task contains 5 bullets (best case), we would only give an estimate for the bullets that we know for sure can be done without further dependencies and complications. We refrain from providing an overall estimate in such cases. * We often proceed with starting a task, and as the task progresses and more clarity emerges, we revise the estimate. Importantly we are encouraged to raise flags as early as possible. * We have dev servers that we spin out frequently to stage things that are in progress to test. They may break but give us early feedback which is crucial. Sometimes helps to stop a task earlier rather than later.
Still not a perfect system, but works for us without causing too much friction.
The absolute best way of estimating development task we've seen was suggested by PHK (of FreeBSD fame), or at least I remember it as one of his suggestions. Basically you take your absolute best guess on a task, multiple that by two, and move up one unit of time.
Example: My guess for task X is 2 hours.
2 hours times 2 is 4 hours
Move up a unit, that's 4 days.
My guess for two hours can realistically be completed in 4 days.
This prevents you from taking on to large tasks, guessing that you could bang out a project in 5 weeks would realistically be a 10 month project. A two year project will be done in 40 years (4 decades).
It not a realistic way of estimating time of cause, but it illustrates the dangers of tackling to large tasks.