I listened to a really good podcast yesterday on Kanban. One of the topics discussed was the fact that with Kanban estimating story points is optional. Most of my agile experience is with Scrum, so my initial reaction was one of mild disbelief. How can a team perform work without estimating effort! But when you think about it, why do we have this vaguely obsessive focus on story points in Scrum? Surely in other areas there are teams that get by perfectly well without having to determine up-front how much effort each item of work is going to require. What is the value in estimating? Here's what I came up with:

• Tracking velocity
• Deciding on the scope for an iteration
• Prioritizing stories (what will give us the most bang for the buck)
• Release planning

I'm focused on the fine-grained estimations for individual stories here, so I'm just going to skip past the release planning stuff. My rationale being that for release planning you're mainly going to use more course-grained estimates for a whole set of features, rather than estimating every single story. As to the value of story points for priotization purposes, I wonder whether there are many times where the decision is based on how much effort a story would take. Even if that was a factor on occasion, I would argue that the estimation process could be done 'just in time' for the relevant stories in the course of a brief conversation.

Really it seems that the main value in estimating story points is to allow a team to sign up for the appropriate amount of work for an iteration. If a team is using a Kanban approach then this isn't really required. A team can just pull work through until they have enough releasable stories. At any point they can decide to make a release with whatever stories are complete at that time. The restriction of a hard timeboxed iteration just isn't required.

So what are we left with? Tracking velocity. Is that actually useful enough to justify the cost of the estimation effort? I wonder. In my own experience it seems that estimating is a relatively painful part of the agile process. Most engineers just find it hard to do it well.

Hidden benefits?

While reflecting on the estimating and planning sessions I've done with teams in the past, I came up with one very valuable side-effect of the estimation process. In order to estimate well a team will need to discuss in detail what's involved in a story. That can often reveal previously unrecognized dependencies, ambiguous or contradictory requirements, and so on. Perhaps there are other processes that would play a similar role if estimating were not being done? For example if a team is doing feature-driven development then they will probably flush out these kinds of issues as they are defining the acceptance criteria for a story. I've not worked on a team that doesn't do story point estimations, so I'm not sure on this one.

It's interesting to reflect that most of the benefit of estimating effort is done in order to support the agile process itself, rather than the actual creation of software. If a team wasn't doing agile, it wouldn't really need to estimate. In that sense it could be considered waste.