Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Is Estimating A Wasteful Practice?

Is Estimating A Wasteful Practice?

This item in japanese

The age old problem of software "estimation" has generated some interesting discussion lately in the agile community. J.B. Rainsberger, Arlo Belshee, Josh Kerievsky, David Anderson, and others ask the question "Are estimates really needed at all?"

Well-known agilist J.B. Rainsberger started an interesting discussion on the XP Yahoo Group that challenges the notion of doing estimation on agile software projects. J.B. recounted a conversation he had with Arlo Belshee, one of the two 2008 Gordon Pask Award winners, about the topic:
[Arlo] told me about some research and practice he has completed regarding cost estimates--notably, not making them. He argued, or so I managed to discern, that the energy that goes in to making and managing cost estimates outweighs the benefit of having them.
Mike Hill chimed into the discussion noting how the folks at Industrial Logic have moved in this direction internally for development of their Agile eLearning products:
For our own work we're finding that a pure 'pull' model works just fine. We 'pull' stories off the top of our customer-sorted stack and implement them. Planning meetings have gotten smaller and focus now on what is most important.
In his "Estimating Considered Wasteful" talk at Agile 2008, Industrial Logic founder Josh Kerievsky had gone into more detail on this. He explained how they were finding success by delivering in smaller, more frequent "micro-releases", enabling them to operate just as effectively using "gut feel" as they had previously with "points & velocity", but without having to spend time putting numbers on cards and doing math.

Not long ago, Amit Rathore had touched on similar ideas. Rathore describes a process where the next most important stories are broken down to a point where they are all of about equal size (a couple days) and pulled into the upcoming iteration in priority order:
Here’s the trick - each story should not be more than 1-3 days of work to implement. Pick the next requirement and do the same thing, keep going until your two weeks seems full.
Rathore explains how this approach not only reduces "muda" (waste), but adds value in many other ways as well:
The fact that this saves time and effort is actually just a good side-effect. The real value comes from being able to truly stay in control of the development process. Tiny stories allow you to change them when required, pull them from the backlog when needed, or to add new ones whenever business demands it. It also lets you move faster because it’s easier to write code in small incremental chunks, testing is easier, and pushing small releases out to users is easier.

And finally, by imposing the discipline that each story be small, it ensures that people think about the requirement deeply enough before coding begins. It also forces the team to break down requirements into incremental pieces and totally avoids never-ending stories that always have a little bit left to complete.
David Anderson made similar remarks quite some time ago, and has been very active in the "Kanban for software" movement since, an initiative with a very strong tie-in to the ideas being discussed by Belshee, Kerievsky, and Rathore.

One might look at each of perspectives and ask "are there really 'no estimates'?", as J.B. had thought of it; Kerievsky and Anderson both say something akin to "gut feel", Rathore says "equal size". Probably not, but is that good or bad? Should the question really be "no estimates?", or should it be "no numbers?" Something else?

Who else has experience running agile projects without estimates? Whether you do or don't, take a moment to join the discussion here and/or on the XP Yahoo Group.

Rate this Article