Hoarding: How to Prioritize Features to Clean Up the Clutter

If you’ve been doing agile for a while, you are no doubt aware of the cost of hoarding and you’ve removed much of it by the simple act of getting your customer to prioritize features and stories then releasing them as soon as you can. By working that way, it usually becomes obvious when you’ve started working on the low-value features, at which point it would be better to move your development team on to the next big project and start working on its valuable features.

But what can you do if you’re not doing agile yet, or if you’re struggling to get your customers to prioritize? Start by collecting data. Go back over the software produced in a sample of past projects and guesstimate what percentage of the features built back then were actually needed. If you can, ask for help and validation from users and customers. You won’t come up with a precise number, and some of the little-used features are—just like the self-destruct button on a space ship—necessary, but hopefully never used. Nonetheless, you’ll be able to come up with a range.

Let’s say the range of needed features is between one quarter and one third of the features built. Now, let’s assume that you could finish each future project 25 percent sooner. It might be more than that, in reality, but it might be less. You’ll never know for sure, so pick a nice round sounding number then start to play around with it. For instance, if you can finish each future project 25 percent sooner just by prioritizing, then that’s like getting 33 percent more staff for free. FOR FREE! And, pretty soon, you’ll start finishing projects before they otherwise would have been started. (Fire up your spreadsheet software and simulate an ongoing series of projects that takes four months in column A and compare them to a series of projects that takes three months).

The next step is the most difficult: If you don’t know what to do with those numbers, then find someone who does (Your boss maybe? Or your bosses’ boss) and ask them for help. Most of us don’t have the skills to have the hard conversations like this.

The first thing your new partner is going to ask is this: I understand the problem. What do we do about it?

There are at least two significant steps. The first is to create a new role called a “flowmaster,” which you can think of as a high-level product owner. The flowmaster’s job is to dish out the potatoes profitably. He manages the list of projects. He decides when each project stops and what new project should be started to take its place. This is a senior role and an unpopular one because the flowmaster has to make some hard commercial decisions.

The second step is to either start working iteratively and incrementally, as we do in agile, or, at the very least, to limit the size of projects. If a project typically takes a year, you’ll want the flowmaster to split it into three or four much shorter projects. That forces prioritization. To put it in terms my Alice might understand: Not only are we going to ask her to not hoard potatoes, but we’re going to give her a smaller plate to make it easier not to hoard. If you still have an appetite for more spuds near the end of the meal then you can always ask the flowmaster (or mum or dad) for more.

One final word of warning: Be careful how you use the word “hoarding.” It’s an emotive term. It sounds like you’re blaming your customers when, in reality, they’re not to blame. They’re just doing the best they can given the way we have traditionally built software. Your two suggestions—authorizing someone to prioritize projects and putting a limit on the size of projects—change the system. Within months, you’ll discover roughly one third more capacity, and you’ll push more projects through your development system than you ever expected too. And you know that scarcity that drove the hoarding behavior? Much of it will disappear as your project backlog shrinks.