Does A Kanban System Eschew Estimation?

I was recently involved in a brief twitter conversation which started when Mike Sutton tweeted:

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 their 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.

7 Comments

  1. So I think 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” is yours, not mine … its quite a leap to think you cant have whole team interaction without a planning game ;). What I talk about is how the XP planning game provides for those things. You’ve explained that there are Kanban practices that achieve much the same. Which makes me wonder whether the whole “estimation is waste” or “its game over for estimation” (http://blog.robbowley.net/2008/08/19/game-over-for-estimation/) is just hyperbole: if you’re spending time in a planning game or modelling workflow to collaborate, learn and forecast is there *really* that much waste being cut from the process? Is the cost *really* that much lower?

    It seems to me that there are benefits to iterations and there are benefits to LWIP … as mentioned in my blog we use both approaches in different contexts. These are the differences that really matter. Estimation is part of working to iterations and is a skill that can be learned and improved. LWIP doesn’t need estimation. What doesn’t follow is that because LWIP doesn’t require estimation, estimation itself is a wasteful, pointless or fruitless exercise.

    1. I was trying to address the comment that “if people find estimation hard, don’t make them do it” which I’m pretty sure is your interpretation of what I said at mini-Spa. On the kanbandev list we moved on from talking about waste sometime ago. Instead we now tend to talk about cost. I think we agree that estimation is a cost that should be paid in context, dependant on the benefit gained. It sounds like for your XP teams, it was worth estimating. Many kanban teams have found ways to reduce their estimation cost.

  2. […] Does a Kanban System Eschew Estimation? […]

  3. Estimating games may be useful in a agile concept, but I think it does start to lose value after a while, especially if it’s the same team doing similar work over time, I think there are other things, like CRC or other modeling that can start a discussion and learning.

    Kanbanians ( is that a word? :)) can estimate, but there is some flexibility to only estimate items that benefit from the estimate.

    1. “Kanbanians” 😛
      Ok, that’s a new word and a like it.

  4. “The team explicitly models there workflow”

    Don’t you mean “their workflow”?

    It doesn’t help bridge the communication divide when we have such a lackadaisical approach to language. All credibility is lost.

    1. Hi Pete,
      Thanks for the catch. Now corrected.
      Karl

Comments are closed.