Slicing, Estimation, Trimming

I’ve written before about estimation, as have many others, some linked to from here, and some not. I even noticed today that Johanna Rothman has a new book about it. I’ve not read it yet but I expect it’ll be quite sensible and pragmatic. Anyway, I’m going to write about estimation again. Today the theme is slicing. Here goes.

Many of us who lean toward or step directly into the #NoEstimates movement try to limit the use of estimates through simple mechanisms like observing progress and using it to predict the future. This is made more difficult because the things that make up progress are “all different sizes” and therefore (some think) we can’t project progress. And there’s some truth to this.

Of course, if we are working in, say, two-week iterations, and we are pretty good at knowing if features are right-sized enough to fit, say, around ten of them into two weeks, then by quickly right-sizing future stories, we could probably do the projection thing.

Some people are tempted at this point to say that this right-sizing is a kind of estimation and therefore we aren’t eliminating estimation after all, hahaha therefore you #NoEstimates guys are full of it.

Yes, well, most of us would be happy to be full of it if you’d all start using this kind of estimation instead of the kind where you try to force us to put a number on whatever vague notion of a feature you have mumbled about, and then you add up the numbers and then you tell us that the numbers are too large and the real numbers are these ones that you made up, and then you demand that we make reality match your numbers, while at the same time you’re changing the things you mumble, adding new mumbled things, and shouting that when you mumbled something that sounded like “purple” you clearly couldn’t have meant “purple” and what is wrong with us can’t we work with perfectly clear requirements and by the way why aren’t we done yet, scurvy scum that we are.

But I digress. Counting things and projecting based on them is fine by most of us, and when we say #NoEstimates, that’s not the sort of thing we mean.

I first started writing about this with the Running Tested Features notion, back in 2004 or earlier. And there have been better ideas since then, many linked to from here and others linked to from there.

A basic notion is this: suppose all features were the same size. If you would just do one feature, and count all the features you want, you’d know precisely how long the project would take. No reason to hassle anyone, just lay down dominoes on the calendar and you know just what’s going to happen.

Wait, tiny #NoEstimates fools! All features aren’t the same size, so your counting idea doesn’t work!

No, you wait: If you’re good enough to size stories so you can do about ten of them a week, then that’s good enough. Size ‘em, count ‘em, lay down your little dominoes and voila! you have a schedule that beats half the schedules in the world.

You want to call that estimation? OK, if you’ll settle for it, we can call it estimation. Knock yourself out.

But wait, there’s more.

Those of us on the cutting edge¹ of Agile use a technique called, of course, slicing. We slice stories into thin bits, each of which is still a story. That is, each thin bit² contains at least a taste of business value, which may or may not be like Penne Arrabiata.

It turns out that you can generally do slicing without anything like estimation. I’ve mentioned before the idea that I learned from Neil Killick, which is to break each larger story down to bits that require only a single acceptance test. This will almost invariably give you something that can be done in a couple of days. If it doesn’t, your acceptance test needs splitting. That topic will be left for another day.

Therefore we can convert estimation into counting by story splitting, which we can do without any kind of estimation at all by slicing thing bits off of our acceptance tests. We can do our projection by counting how many thin bits we’ve gotten done over time, and looking at how many we have left to do.

I conclude that counting is easier and more effective at getting the end date than conventional estimation, and that slicing is a good way to get to counting. Therefore the #NoEstimates people aren’t completely crazy. Defense rests. People who think estimation is necessary, or a gift from G*d, bugger off.

But wait, there’s more …

Suppose this upper square represents some big story, and that we slice it as shown in the lower story. Each of the slices represents some acceptance test, and each slice is small enough to fit into our counting scheme. But when we look at those slices, we see that a couple of them aren’t as important as the others. They’re frills or desirable features that don’t add as much value as the others.

So we just don’t do them! We slice them right off, as in the picture above. In this made up example, we save forty percent of the cost of the original story. We can move right on to something else important.

Every set of requirements has fat in it, or items of lower value. Every large story has smaller stories inside it, some of higher value, some of lower. When we split them, and when we work closely with our business-side people (daily, as the Manifesto asks), it becomes easy to trim the fat out as we go.

Slicing trumps estimation. Better yet, it reduces the overall cost of getting to any desired level of value, by ensuring that we always add high value stories, and high-value slices within stories.

Get into slicing now, and you’ll get not one, but two returns on your slicing investment. In just zero payments of $39.99! Call now, operators are standin by.