Estimation and Waste

There’s been some discussion recently on InfoQ and in the XP Yahoo! Group, as to whether estimation could or should be considered as waste.  My recent view has been that estimation is waste, but I think I am refining that position to be that “traditionally recognised” estimation is waste, and that there are subtleties which mean that some sort of estimation still has value.  I’ve put together the following 3 differentiations about how estimation fits into a kanban system for software development.

  1. Estimation can be implicit.  Traditional estimation usually involved some sort of explicit meeting or event where the estimates are determined.  The most common Agile format is Planning Poker.  An alternative technique which use a more implicit format are aim for each work items to be equally sized, thus reducing variation and enabling smoother flow.  Obviously, in order to figure out if items are equally sized, some form of estimation must take place.  Amit Rathore has written about this.  Similarly, a basic classification could take place, such as T-shirt sizing, in order to determine relative sizes.  In both these approaches, however, the focus is on measuring and improving throughput and cycle-time, rather than making planning predictions.
  2. Estimation can be course grained. The granularity and precision of estimates is relevant.  A common concern with ‘estimation-less’ development is how forecasts of time and cost can be made.  This forecasting can be made without story points by working at a higher level, and focussing on what goals can be met, and what problems can be solved.  This can probably still be considered to be an estimate, but its very low granularity, low precision and more ‘gut feel’.
  3. Estimation can be about quantity.  Estimation shifts from asking “how long” items will take, to “how many” items can be done in a time-frame.  By measuring throughput and cycle-time, this estimation becomes much more measurement based, assuming you have either same-sized, or categorised items as described in point (1).

All in all, estimation is a means to an end, rather than an end in itself, the end being reliable forecasting and delivery of projects.