estimation is not about the number that pops out. It is about exploring effort and discovering that you don’t know stuff.

Paul Dyson responded:

spot on! This is fundamentally what I don’t like about the kanban “if people find estimation hard, don’t make them do it” mantra.

Which is where I jumped in:

where did you hear that “kanban mantra”? Not one I’m familiar with.

Only to be told:

err, it was actually in the talk you gave at mini-Spa!

Since then, Paul has blogged some more on estimation, and this is my response, hopefully clearing up what I said, or at least meant to say at mini-Spa, in addition to what I’ve already written on estimation and waste.

A simple summary and paraphrasing of Paul’s post would be:

Estimation, as part of time-box planning, leads to whole team interaction and collaboration, to create learning about past capability and forecasts of future capability

Lets start by drilling into these key points from Paul’s post. Essentially the implication is that by eschewing iteration, we cannot have whole team interaction and collaboration, cannot learn about past capability and cannot forecast future capability.

Whole team interaction and collaboration

I can think of 3 ways a team a whole team can interact and collaborate around planning a new piece of work without estimating in a time-box planning meeting:

• Cadence. The team agrees a cadence at which they will all get together to collaboratively plan new work. This planning cadence looks at what new items the team may be able to pull, given their current work-in-process, rather than estimating what items they may be able to complete.
• Workflow. The team explicitly models there workflow to make transparent that fact that they need to get together to plan new pieces of work when they are pulled. This stage could be a stage called “Planning”, or even ”Analysis”!
• Just do it! When the team pulls a new work item, they spontaneously swarm on it to plan it. This probably requires a small and high performing team.

Even so, this is assuming the whole team really does need to interact and collaborate on every piece of work. However, not every piece of work is equal, and there may be some smaller, simpler features that can be planned and delivered by a smaller group.

Create learning about past capability

We can learn about our past capability by measuring data such as cycle time, and tracking it with a Statistical Process Control chart. Common cause variation is to be expected within a stable system. However, special cause variation is something we can look at in more detail to see what we can learn (as long as we don’t change the system in response to special cause variation).

Forecast future capability

Once we understand our past (or current) capability we can use that information to forecast future capability. By understanding how long things have typically taken in the past (with natural variability) we can determine how long things will take in the future (with natural variability). Dennis Stevens has recently written some great posts discussing knowing when we will be done, using classes of service and service level agreements to manage variability.

So kanban teams do not eschew estimation simply because it is hard. Some teams choose not to estimate because they can realise the same benefits that estimation gives with a lower cost. The old joke does still apply (“Doctor, Doctor it hurts when I do this”, “Don’t do that then”). If it hurts to estimate, then find other ways to encourage whole team interaction and collaboration, learn about past capability and forecast future capability. On the other hand, if estimation doesn’t hurt, or costs too much, then it may be the right thing to do in your context.

What I think we do agree on is that when we are planning, we should decompose work for understanding, rather than sizing (thanks to Eric Willeke for this phrasing). As Mike says, the estimate is just a number that pops out of the discovery.

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.