I expect to ruffle some feathers with this post.

I see a lot of people stressing out over the predictability of their software teams or projects.

I think most of this stress is wasted. Not only is accurate prediction (beyond a few days or maybe a couple weeks) literally impossible in this domain, it’s usually not useful, even if we could have an accurate prediction.

Unless you’re betting on a horse race, knowing exactly when a thing will happen usually doesn’t provide business value.

That probably sounds ridiculous to many of you. And there are some exceptions to the rule, but they’re so rare that I think they serve to reinforce the rule. Let me try to explain with some examples.

First, let’s talk about the #1 reason I see people asking for accurate predictions/estimates: Capacity planning. This is often done in the form of story-point Tetris, to know exactly how many items to give to each developer on a team. Sometimes it’s a bit more nuanced. But however it’s done, in the majority of cases, this activity provides no business value. Virtually every team I’ve evern seen or worked with that used estimation/prediction for capacity planning should not have bothered with capacity planning at all. I’ll admit, there are some cases in software development where capacity planning on the short-term scale of a Sprint or similar, may be useful. But they’re pretty rare. And it’s also not how Scrum is even meant to be practiced (at least not according to the latest Scrum guide).

The next most common reason I hear cited for needing estimations/predictions is to meet deadlines. Ironically, true deadlines are exceedingly rare in software development, but they come up in conversation all the time. Regardless, the funny thing is, you don’t need predictability to deal with deadlines, either! Incremental software delivery makes deadlines (almost) meaningless.

(The only exception to this rule I know if is when the question is whether or not you can deliver a meaningful amount of work before the deadline. Here some level of predictability is needed, but with very coarse accuracy.)

This brings us nicely to the third reason I hear for needing predictability, and that is for roadmapping. “We need to know how long it will take to deliver feature X for Bob, so that we can tell Alice when we’ll start on and then complete her feature Y.”

This reason is almost legitimate. But only almost. You see, this is really just another case of story point Tetris, but at a higher abstraction level. Rather than planning features to the quarter, or month, or year, we should be focusing on the most important or most valuable feature. Then we iterate on that, until it’s no longer the most important or valuable (either because something of higher value/urgency has come up, or because we’ve already delivered the highest value functionality).

This leads to the final reason for predictability I want to address. And this one has some actual merit to it. It’s also pretty rare at most companies, but when it matters it matters. And that reason is: Long-term capacity planning.

Suppose Alice’s project Y will need the full attention of the current team, plus a new team that hasn’t been hired yet. In this case, you need some significant lead time to hire that new team. But you also need to know when the new team should start working, because you don’t want to hire 8 new people with nothing to do while waiting for the previous team to finish Bob’s feature X.

This is a case where knowing when Alice’s project Y will begin represents an actual business need. And by extention, it means knowing when Bob’s project X will finish is tied directly to business value.

However, in the majority of cases, a scenario like this can often just be turned into a deadline. “Tell Bob we’ll deliver his feature X at end of Q2, then we’ll start on Alice’s feature Y.” Now you have a deadline. And as an agilist, you know how to deal with deadlines.

I know I’m glossing over a lot of details. And those details often matter.

My goal here isn’t precisely to make a dogmatic claim that predictability is never useful. Rather, I want to challenge the idea that predictability is inherently useful. It’s not. It’s only useful when it serves a business goal. And many of those business goals can be served as well, or even better, by other means.

Is the predictability you’re trying to achieve in service of a business goal? Can you actually name that goal? Can you draw a line between your predictability efforts and tha goal? And what happens if your predictions prove wrong, despite your best efforts? How will that impact the business?