The estimate wouldn't be a deadline or for billing purposes. It would be more of a tripwire for "this task needs attention" to make sure a developer doesn't ge

The estimate wouldn't be a deadline or for billing purposes. It would be more of a tripwire for "this task needs attention" to make sure a developer doesn't get bogged down in a task that he / she is unwilling to admit defeat on. Sometimes all that is needed is a fresh perspective from someone else to look at the task and offer a different approach. Think about those situations where you bang your head on a wall for far too long on a problem and then take a break or sleep on the problem and then fix it immediately when you get back to the task. Another developer could also offer this fresh perspective. The task may simply be bigger than originally estimated and the discussion may be no more than "okay, adjust the estimate and keep doing your thing." Also, in some cases there actually would need to be a deadline and there would need to be pressure. It depends on your situation. X startup working on their own application may have wiggle room for their timeline, but I do mostly client work where our deadlines are pretty much set. Often I need to give estimates which the rest of the team will use as part of tracking and projecting the overall timeline as well as setting the expectations for the client. I agree with you though. It sounds like you guys have a great setup.