That's why we were using complexity estimates in points (say 1 to 5) instead of actual time estimates in my last startup. Once you have some worklog, it's easy to calculate how many points the team can get done in a week (or whatever your estimation cycle is). This little abstraction made estimates much more reliable.
I guess some "agile" methodologies propose a similiar approach, but we didn't really follow any specific one, just figured out what works best as we moved along and kept the process as lean as possible.
Just to clarify what k7d is saying when he quotes "agile" methodologies:
Any prescriptive agile methodologies (first, do X. then, do Y) are really antithetical to agile. True agile processes are exactly what his own startup did. They used what worked. They implemented a practice (complexity points) that was relevant to their principles (accurate estimation). Of course, you should also be tweaking your process as you go along.
There's another way as well; specify a range of time within which you expect the task to be completed. This also communicates your uncertainty about the estimate at the same time.
I guess some "agile" methodologies propose a similiar approach, but we didn't really follow any specific one, just figured out what works best as we moved along and kept the process as lean as possible.