Where I work we don&#x27;t estimate in time, we estimate in points. Points are intended to represent engineering&#x27;s view of the relatively complexity and uncertainty of a given story.<p>Pivotal Tracker then looks at story delivery over the past 3 weeks and gives a simple average: velocity. You can then look forward to see approximately when future stories will be completed. You can also see a volatility measurement, which characterises how much velocity is fluctuating.<p>Our horizon is deliberately short, because we move very quickly.<p>Nevertheless, it has a simple advantage: it is based on the true and most recent data of the exact project you are estimating.<p>Other estimation techniques are useful in other situations, but simply being able to say &quot;those are the <i>actual numbers</i> for <i>this</i> project <i>this month</i>&quot; is enormously powerful. There&#x27;s no fudging. The numbers are right there in black and white.<p>It usually takes a little while for people new to this approach to accept that velocity is not a target; it&#x27;s a measurement only. It&#x27;s a unitless measurement that is only meaningful within a single project, operating at a floating exchange rate with calendar days.<p>One last thing that helps, as others have pointed out. Break down your estimation tasks into smaller units. Never accept the small headline that hides a big feature. Continuously look for seams to break big stories into small stories. When the pointing begins, summarise aloud with fellow engineers a rough idea of what will need to be done.<p>Psychologists call this the &quot;unpacking effect&quot;, and I suspect that it&#x27;s responsible for most of the estimation-increasing power discovered in more fully-dressed estimation techniques like PERT, parametric estimation tools or even good old fashioned checklists.<p>(I was working on an estimation tool for a while, so this subject is dear to my heart).