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.
- 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.
- 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’.
- 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.
The challenge with No. 2, often found in service based organizations, is that clients need dates along with the estimates that get tied to a SOW. You may be Agile, but your clients may not be. It can be challenging and take time to get them to understand the value of developing software this way. I am struggling with this problem. The estimates are fine… but then you are put in a cast. I have yet to see much in the way of how best to structure service based contracts in an Agile environment, when your customer is not Agile. This is where estimation can have the biggest impact.
Hi hbflynn. If the client isn’t agile, and the estimates are needed for a contract, then you should estimate. However, I still feel it is waste, as it isn’t actually adding any value to the final deliverable. That being said, if you have a fixed date, then you can still estimate “how much” (3), which is easier if you have same sized, or classified (1).
[…] who claim that estimating is simply a form of waste; I first heard this from Karl Scotland who has blogged about his thinking and who I hope will comment further on this subject. This seems to appeal to developers who find […]
Hi Karl,
If estimation is waste, then what do you suggest as an alternative? In any case, all of your 3 points above revolve around the traditional meaning of estimation.
Hi
I talked more about Kanban and Estimation in this post:
https://availagility.co.uk/2010/07/14/does-a-kanban-system-eschew-estimation/
Does that answer you question?
Karl