Whenever I find myself expressing “anti-” thoughts I think back to a wonderful trick that I learned from Arlo Belshee and James Shore. They ran a workshop about integrated tests where they asked what benefits they give us, rather than focusing on all the problems that they cause. When they did this, the discussions in the room became so much more constructive than the ones I’d seen online. Not only that, but we (mostly) stopped dwelling on the problems we faced, and instead shared numerous ways that we get those same benefits by other means. It can also help find essential benefits that we don’t get by other means, and encourage us to look for alternatives. I felt much better about the whole experience, and as I use this technique more, I notice that I spend much less time wallowing and much more time progressing in my work.

You can guess where I’m going with this.

What benefits come, then, from task/story-level estimates of the type that I generally mistrust? (Remember: I don’t literally mean “never estimate” by #NoEstimates.)

I’ve watched dozens of teams and hundreds of programmers estimate small pieces of work—anything not more than about one month of effort—over the years, and the discussions that ensue can sometimes contain magic. It doesn’t happen as often as I’d hope, and it seems to depend a lot on how well the participants trust each other. Some of these discussions lead to incredible “Aha!” moments that sometimes save us weeks of effort and sometimes open up a most uncomfortable can of worms. These discussions have one consequence in common: they reveal significant assumptions about the work in question.

Suppose you and I estimate a story together. Suppose we’re playing some form of Planning Poker. You estimate “8” and I estimate “3”. (Neither the scale nor the unit matters for now.) We each argue for our position. You point out problems with the design in some part of the system, which makes you believe that it’ll cost more to deliver the feature.1 You also raise concerns about how well we understand the finer points of the story and that our resident subject matter expert already finds it hard to spend time with us. I venture that we don’t have to worry about any of that, because we really only need to build some simplified version of the story. You see, I bought our subject matter expert a cappuccino yesterday and went over some of those murky points, and we have much less to worry about than even I thought we had two days ago. Within minutes we agree that an estimate of “3” probably fits the work much better than “8”. We move on.

I wish this happened more often. Unfortunately, I also see many other outcomes from similar situations.

  • Some product owners/directors/shepherds routinely yell at those who they believe routinely estimate “conservatively”.
  • Some architects/senior programmers/technical leads routinely yell at those who disagree with their estimates, insisting that they know best.
  • Some product owners/directors/shepherds yell upon hearing higher-than-expected estimates, even when the team agrees on those estimates. They pressure the team to make the work fit in the expected time available.
  • In some situations, someone has already committed the team to delivering the work, making the estimates moot.

I notice one common thread among these situations:

If you beat an animal often enough, it will stay down.

Or, if you prefer:

If you yell at me often enough when I think I’m trying to help you manage risks on the project, then I will eventually stop trying. Eventually, I will stop thinking about the story we’re estimating, and instead offer a mindless estimate that I think you’ll accept.

I had situations like this in mind when I tweeted

In his article “Surfing the Plan”, Gene Hughson highlights the link between communication problems and dysfunction related to estimates. He describes an approach to estimating that I quite like: stop using plans (and estimates) that have crossed their best before date (or expiry date). XP makes this explicit by encouraging practitioners to revisit their estimates in every planning cycle,2 perhaps naively assuming that every estimate expires after two weeks. (Not a terrible default assumption, I don’t think.) The notion moves me more, not less, in the direction of mistrusting estimates. Why spend so much effort producing something that expires so soon after we produce it? (This ignores, for now, the question of whether anyone is even consuming it.)

Estimating Over Estimates

This brings me to the pithy maxim I’ve heard for many years: estimating over estimates. I don’t even remember where I first heard or read it, but it has lived on in my work for well over a decade. When people who trust not only each other but the people managing their work estimate small pieces of work, they readily (although sometimes painfully) reveal potentially contradictory assumptions about that work. People working together with contradicting assumptions about the work presents a significant ongoing threat to the results of that work. I argue that the estimates themselves provide precious little value compared to the act of estimating.

I’ve seen this kind of idea before. I see it as a running theme in Liz Keogh’s work in Behavior-Driven Development: the conversations matter more than the scenarios. Similarly, I find that assessing the cost of the work matters more than the cost estimates. Even better: this parallel brings me back to the beginning of this article.

A Practical Alternative to Estimating

So far, I’ve made these claims:

  • Task/story-level estimates routinely cause more problems than they solve.
  • The act of estimating with people that we trust helps us reveal significant risks in the assumptions we make about the work.
  • The act of estimating with people that we don’t trust leads eventually to ritual, Cargo Cult, whatever you prefer to call it.

So how do we get the benefits of estimating without the drawbacks of estimates? I use the conversational techniques of BDD, which work tremendously well at identifying previously-unstated contradictory assumptions about the work we intend to do. Curiously, I have also noticed that fewer people hide details from one another, even in environments of dubious trust. I don’t yet understand why this happens, but it does seem to happen. This leads me to offer BDD (broadly-speaking) as an alternative to estimating.

Now you might conclude that practising BDD and exploring stories/tasks in detail will lead naturally to more accurate estimates, which means that I really don’t mistrust estimates at all! No. If you thought this, then you need to read this article which highlights another, even more significant obstacle to accurate estimates.

Need Help?

If you’re convinced and want to get started, read the references below. Read the other articles to which those refer. Find a book or two about BDD. When you’re ready for more personalised help, then please tell me and we’ll determine together whether you’d benefit most from training, coaching, or consulting.

References

Liz Keogh, “Step Away From the Tools”. I cite this article every time I teach Product Sashimi, my particular approach to incremental product delivery.

Liz Keogh, “Conversational Patterns in BDD”. A practical example of how the conversations of BDD help us identify risky assumptions about our work.

J. B. Rainsberger, “Three Steps to a Useful Minimal Feature”. A worked example of one of the key techniques of Product Sashimi: slicing features into valuable, deliverable pieces.

J. B. Rainsberger, “How You’ll Probably Learn to Split Features”. An overview of the stages that most people go through as they practise the conversational techniques of BDD.

  1. I’ve both recorded and transcribed a lightning talk that describes this phenomenon. Click here to read or see more.↩︎

  2. Of course, this implies that we don’t estimate every piece of identified work in detail, because then we’d never have any time left over to deliver features. The rule encourages us to limit work in process (if you like Kanban terms) or investment (if you like Theory of Constraints terms) without explicitly calling it that.↩︎