I have been reading David Anderson’s wonderful book on Kanban this week as a means to get more specific on the project improvements I want to make based on what I’m learning with Lean Enterprise. This book has disrupted up my approach to backlog management and prioritization. Within a Scrum or Waterfall process, whenever a customer asks for a request, you put it on a list and regularly prioritize that list. The backlog as a whole is the input queue in the system.

Currently, there are 397 issues on our backlog. We can’t possibly be meaningfully prioritizing all of these.

In a Kanban system, this is seen as waste. Why spend all this time prioritizing something when only the top five things at any one time are important? Is there a way to communicate to users that we just won’t get around to certain things?

At Corbis, Anderson tried something different: he figured out how many items that were needed in the input queue to keep the system going. In other words, we don’t want to be caught not knowing what to do next, so what number of items in the input queue would keep that from ever happening? Usually the number is less than five.

Every week the team meets with the stakeholders and asks the simple question, “What are the most important

X things to do next?” These items can be pulled off of the backlog, or they could even be new. The stakeholders can discuss what the most important changes are and why. The important items are determined and then the changes flow through the system.

Now that this discussion is happening regularly, the territorial fighting should decrease. It’s up to those in the meeting to come to an agreement on what is next. If your thing isn’t done this week, then perhaps it will be done next week. Nothing is set in stone.

After a few months of this, it should become apparent that some items on the backlog have very little chance of getting done. Therefore, if a backlog item is more than six months old, we should close it. We can always reopen it if is a priority, but it keeps open communication with those requesting changes about whether to expect the change anytime soon.

Yesterday in a project meeting one of our senior developers recommended that we focus more on ensuring buy-in from teams that we are serving for what we are doing. At the time I was focused on how to define appropriate metrics and so didn’t know how to implement her point. But now I see that if I follow this pattern of input queue management, I’ll be able to bring together stakeholder’s desire to have something right now and their ability to ensure that no other teams are blocking us from creating that outcome. I’m really excited to see how this suggestion will work for us.