A Matter of Definition?

A few tweets last night gave me a small but useful insight into the #NoEstimates controversy:

Taking that conversation at face value, we see that Glen Alleman says that estimates are the only way he knows to make an informed decision about the future in the presence of uncertainty.

Now, suppose that we think there is another way. There are at least two possibilities:

1. Glen has never heard of that way.
2. Glen defines that way as a kind of estimation.

I hypothesize that the case in hand is #2. Here’s another series of tweets, where Glen asked for an example. Glen did not reply to it but Peter Kretzman did, in typical fashion:

To me, this confirms two things. One of them is like #2 above: Peter considers the process of catching a fly ball to involve estimation.

One good way to catch a fly ball is to hold up your gloved hand at a constant angle, and run so that the falling fly ball is directly aligned with your glove. If the fly ball appears above your glove, it is going to go over your head: move back. If it appears below your glove, it is going to fall in front of you: move forward. Left of glove: move left. Right: move right.

I’m guessing, but I’m pretty sure these gentlemen would say “That’s a form of estimation”.

Now that happens to be quite different from the way Glen recommends estimating software projects, which, if I remember my reading, involves collecting a lot of detailed information about similar work, classifying the proposed work into similar bits for which we have data, and using the past data to predict the future. (I’ve tried to do justice here to his comprehensive writings on how he estimates the projects that he estimates. If I’ve fallen short, I’ll be happy to replace this paragraph with a better one of similar size.)

There’s no doubt that what Glen does works: he reports that his projects come in on time and on budget. And there’s no doubt in my mind that if you had comprehensive data on how long things took in the past, and you were doing new work such that the work, the team, the circumstances were sufficiently similar, you could use the data to predict that new work.

That is one way to predict how long a project will take and how much it will cost. It seems to be a good way for Glen, because he is successful with it. It’s not a good way for people who do not have a lot of data, or whose new project and team is not sufficiently like the past to come up with a good match.

Such people exist, by the way. I’m one of them: I moved my old web site xprogramming.com to ronjeffries.com, starting last year. I’ve written a number of articles about that process, talking about how hard it was to estimate. Possibly it was hard because I’m an idiot. But I think not, based on several different measures, including that in fact I got the web site running the way I wanted.

Along the way, I discovered a lot of things about the conversion that I did not know at the beginning. Those have been written about elsewhere.

So I would argue that I built the web site without estimates — using my sense of the word.

But I digress

Glen and Peter appear to use the word “estimate” in such a way that any activity that involves any kind of prediction of the future is an estimate. Catching a fly ball involves estimates. OK, this is a useful discovery. And it’s not what I mean by estimates.

OK, Ron, what do you mean by estimates?

Thanks for asking. In the context of these articles I mean, primarily, two activities:

First and foremost, I am generally referring to the common iteration-by-iteration activity of having teams estimate how long features (stories, tasks) will take. This is typically done in person-days, or in some kind of “points” that are translated into days by observing how long it takes to get points done. For now, let’s call this “story estimation”.

Second, I sometimes refer to the activity of figuring out how long a project will take and/or how much it will cost to do it. This is typically a one-time activity, done before the project is authorized, although the question will likely be revisited as the project goes on. Let’s call this “project estimation”.

In the interest of space and time (I estimate), we’ll just talk about story estimation here.

Story Estimation

My view is that story estimation is wasteful and often misused. The base process in an “Agile” project is to look at the prioritized backlog of work, and select a quantity of work that can be done in the upcoming iteration. (This is, of course, an “estimate”. If you’re playing the Semantics Game, you win, but my point is that this is commonly done by estimating each story, and that there are other ways to select the work.)

Talk about how long it might take

You can select the work by just talking about it, possibly kicking around the time you’d need, but never formally putting down any numbers, and then saying “Let’s take on these six, but not the seventh.” That’s estimation, but it isn’t story estimation. We’re here to deal with story estimation.

Select by intuition

You can select the work more intuitively than that. You can just talk about how you’ll do the various things and at the end of the meeting say “Let’s take on these six, but not the seventh.” Again, no story estimation.

Slice the stories

You can slice the stories. That means breaking them down into simpler stories that sum up to the more complex story you originally had. And it turns out that you can slice them without estimating. I learned this trick from Neil Killick: consider the acceptance tests for each story. Make each test as simple as possible but still showing something about the story. Then do simpler stories implied by those tests.

It turns out that this practice often results in stories that will all take about the same amount of time. (I don’t know what that amount is: in my experience, it might be a day or two, or it might actually simplify them down to a couple of hours’ work.) No matter, what you do is observe how many of these simpler stories you tend to get done, and take on that many.

This, too, is of course estimation, but it’s not story estimation. You could create a story estimate if you wanted to, by counting the simpler stories, but why would you bother? Your interest is in getting things done.

Do slices in order

You can just do the slices in order. You might not bother even to say how many slices you’re taking on in the iteration: you might just start doing them. You finish each one, then move on to the next. When the iteration times out, maybe there’s one more slice in process. If you don’t like that, you look at the calendar once in a while before you decide to start another slice. (Yes, you’re estimating whether you can be done by Friday.)

None of these are story estimates

You might wish to call these ways of working “estimates”, and if you do, you are generalizing further than I would with the term, but OK. The point is, they are not story estimates, and it is those that I would like to do without.

Is this #NoEstimates in the sense of “absolutely no estimates”? Obviously not. But it does show that a particularly troubling kind of estimate can be done without.

What did we learn on the show tonight, Ron?

It’s possible to take the position that all means of predicting the future are “estimation”. If one does that, then one needs to be aware that that’s not how other people are using the term. For productive discussion, if one wants that, one needs to be working from common meanings of terms.

If all means of predicting are estimation, end of discussion, there’s no more to talk about at that level.

We could, of course, talk about “story estimation”, but the same reduction can occur. If assigning and tracking person-days or points, or using intuition, or slicing with counting, or slicing without counting are all story estimation, then, again, end of discussion.

But I made up that term, just now, so let’s use my definition while you’re here. I’m suggesting — and most of the other #NoEstimates people are suggesting — that the other practices mentioned are better, in some important ways, than the thing called story estimation.

Now, if you want to win the discussion about #NoEstimates, you can say that I’ve not been clear about what I mean, or that my terms are poorly chosen, or that my mother dresses me funny. Great, you win the discussion.

But if you want to learn from or even contribute to the #NoEstimates topic, then you need to begin to deal with the terms and ideas as they are used, and to deal with the people who are working with these ideas. There’s no law that you must do that, but standing on the sidelines throwing stones will not likely advance anyone’s real understanding.

Those of us who are working with the ideas that someone called #NoEstimates are discovering that there is value in choosing work and budgeting projects differently from conventional ways. We’re interested in figuring out how those things work, turning experience into theory, perhaps one day turning anecdotes into data. Mostly, we’re interested in things that make our projects, and those of our colleagues, go better.

The whole point of “Agile” and related thinking is to observe what’s happening where you are, and adapting what you do to make it go better. When an adaptation doesn’t make things better, you adapt again. You build up an intuition as to what works. You might build up and test theories. You might collect data. Mostly, you try things, you learn, you internalize.

People have the right to join into that conversation in any way they please, including casting stones at the ideas and the people who are working with them. That may be some kind of contribution, if only because it challenges other people to gain better understanding of what they’re doing and to learn better ways of expressing what they’re doing. I’d prefer a more collegial approach, and choose to engage stone-throwers as little as possible. I still engage them more than I likely should, but occasionally it results in a bit of insight such as expressed here.

You keep using that word. I don’t think it means what you think it means.
– Inigo Montoya