Estimates as Sensors

Note: this is not an April Fool – honest!

I’ve been watching the #NoEstimates conversations with interest and decided its about time to pitch in with my own perspective. I don’t want to take any ‘side’ because like most things, the answer is not black or white. Estimates can be used for both good and evil. For me they are useful as a sensing mechanism. Put another way, by estimating, I can get a sense of how well I know my actual capability.

Lets take an example. I’m taking part in a 10K run this Sunday (*) and I am estimating that I will complete the distance in 55 minutes. This is based on an understanding of my capability from participating in regular 5K runs, and more general training runs over a 10K distance. I’ve never run an official 10K race, let alone this course, and I don’t know what the conditions will be like, but I’m aiming for 55 minutes. If I run quicker and do better than my estimate, then my actual 10K capability is better than I thought. If I run slower and do worse than my estimate, then my actual 10K capability is worse than I thought. Either way,  I will learn something about how well I know my 10K capability.

What helps even more with that learning is regular feedback! I use MayMyRun on my phone to track  progress and give me feedback every kilometre for total time, average pace and last split. This could be considered a distance-based cadence. I could probably also use a time-based cadence to give me equivalent feedback every few minutes. This feedback on a regular cadence helps me decided whether my estimate was way off, or if I should slow down because my pace is probably unsustainable, or speed up because I feel I can push harder.

How does this relate to product development? Well, we can use estimates in the same way to get a sense of a teams delivery capability, and use regular feedback to learn whether we’re making the progress we thought, and need to re-plan, slow down or speed up. Time-boxing, with Story Point estimates and Velocity can provide this time-based cadence and feedback. Alternatively, how long it takes to complete 10 User Stories can be used as a distance-based cadence and feedback.

To sum up, I recommend using estimates to sense capability and create feedback for yourself. I don’t recommend using them to make promises and give guarantees to others. Or maybe we could just call them sensors instead of estimates?

(*) Of course this post is primarily an excuse to invite readers to sponsor me. If you’re so inclined, or would like to show support for this post in a charitable and financial way, then please head over to my JustGiving page and do so there 🙂

Update: My final time was 49:23 based on the timing chip, or 49:30 from the starting gun. I’ve learned that I’m better than I thought I was, and next time I’ll be estimating 50 minutes!

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.

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.