This is an edited version of a post I wrote to kanbandev on 10/22/2009. The thread was started by somebody asking about work decomposition and how it relates to estimation, and asking why we have been saying that estimation doesn’t have value. Disclaimer: This is all "in my experience" and may not represent the views of anybody else.
Goals of estimation
- People that ask for estimates are generally looking for commitments on when something will be "done", which seems to mean "earning or saving money".
- Teams and people doing estimates of their own volition are generally looking for the understanding of the work that comes from estimating and breaking down the work.
- Teams doing estimates also use them to expose inconsistencies of understanding (i.e. planning poker)
- Related to #2, but teams additionally use the estimation process for finding dependencies among work, and as a more general planning tool
All of these are good goals to have and to do. However, estimation is just the mechanism we’re using to accomplish these goals. It was a reasonably effective mechanism in the right hands and a horrible one in the wrong hands.
- Instead of estimating, we commit to a generalized Service Level Agreement for a given class of service and just slot items into those classes. Individual items may miss, but on aggregate the commitments are pretty solid as a result
- Pairing & swarming are both great tools for exploring the work and sharing that understanding, especially when the customers are involved in the process
- The work gets done so quickly with swarming that the inconsistencies are driven out VERY quickly, and nobody works alone long enough to propagate those misunderstandings. (But, beware cult of personality)
- This is the expand/collapse pattern, and the work breakdown tends to occur as soon as the team starts a bigger item, the dependencies are figured out as part of the expansion, and the loosely ordered items are pulled through very quickly. Each level of expand/collapse has its own internal ordering dependencies, but these generally don’t cross levels much.
This is a general and very effective behavior I’ve seen when looking at lean approaches to evolving the way we work. Instead of looking at a practice as a tool, it’s very useful to back out a level or two and look at the goals that practice was meant to accomplish and even further to the principles and values backing it. When I do this, I often find myself seeing other practices we could do (or already do) that accomplish the same goals.
Scrum is a very nicely balanced set of practices that work great in the proper context because they collectively cover most of the goals that we need to cover as an agile development group. My criticism of Scrum is that when it doesn’t fit the context, the perception is that you should change the context to fit Scrum rather than the other way around. The danger in changing Scrum is in failing to understand the goals of the practices. Dropping estimation is a very bad idea if you don’t have another way of making your commitment, for example. Dropping sprints is a bad idea if you don’t have inspect/adapt, commitment, delivery, etc all covered. Blindly changing is just plain stupid.