Stop wasting time on the backlog!
Consider the ongoing development of a software based product, and the constant struggle of figuring out what to improve and what to build next.
Should we build feature A or B sounds like a simple question. The problem is that most product owners don’t have two things to choose from, they have two hundred. Some have two thousand. How to choose between them? Half of them are probably a couple of years old, how do we know they are even relevant anymore?
This post won’t help you figure out what to choose, but it will make the process more effective.
Many teams have a Kanban board for their development process, but it is less common to include the discovery and selection process needed to figure out what to build.
A simple set of columns before the actual development process could look something like this:
If you have a larger product team, you’d likely also have a step between New and Discovery consisting of some kind of meeting to figure out what to pick.
To keep this as simple and effective as possible, you’d want to connect this directly to the development board. A simple Kanban board for a development team may look something like this:
Todo -> In progress -> Developed -> Acceptance test -> Done
The trick now is to connect these two by replacing the first column (Todo) in the development process with the final column of the discovery process (Build this next). Result:
The columns and policies for each state could be different for you, the main point is that you set up a visual representation that includes the backlog process. Or one of the main points. There’s another important rule in Kanban that you need to make this really useful: Limit WIP (work in progress).
If you do both, you will have a very neat way to optimise the process of both grooming the backlog and getting the individual items ready for development. Let’s digress into some background about what the problem is, before I explain how what we just did can solve it.
As indicated above, it’s quite common for product management to have a somewhat disconnected process for backlog processing / grooming / triage. They also typically have a large backlog full of important(?) things. This is the key to a lot of waste for anyone involved. We want to do a lot more than we actually have capacity to build, but we refuse to accept this fact. The result is that we discuss, process, specify and prioritize all of it.
Say you have the development capacity to build on average 5 items each week, and you have 250 in your backlog. Any given week you get several new ideas to put back into it. So while your backlog stays at a steady 250 due to the continous flow of new ideas, you get 5 items or 2% done each week. This is the reality of many software development teams.
Most teams have processed all items in their entire backlog at least once, and quite a few have even been processed several times. Why? They’re important, but not important enough. So they’ve been revisited and reprioritized without quite making it to development, and many are so old that the requirements may have changed several times as well.
In our example, any given week we have 245 items (a whopping 98%) in our backlog that we have spent time working on (analysing, requirement gathering, discussing, prioritizing), but are not delivering. Over time, this adds up to a tremendeous amount of work in progress. Exactly what value do we create by working on all those things, many of which will never even be built?
It is starting to sound like limiting WIP on our backlog process could really save some time. So now what?
First we need to limit the size of the backlog itself (by backlog we refer to our Ideas column). Setting a hard limit may not make sense, so what are the alternatives? Consider your capacity as well as all the other important stuff you already plan to build in the upcoming months. Based on that, is there’s a reasonable chance this new idea will be selected for development within a year? Be honest. If not, discard it right there. It will never make it into production. Before that year is gone, you’ll get a boatload of other ideas that may be of higher priority. Ideas that you do put in the backlog, but end up never getting to, should be automatically archived by a policy that says delete all items older than whatever (i.e 13 months to account for annually recurring issues).
Then to the best part, and in many ways the main point of this post:
Set WIP limits that constrain your entire backlog grooming process, and try to stop saying “maybe later”. For our example of 5 items delivered by development each week, try starting out with a WIP limit of 10 for the inbound queue to the team. The right number depends on your delivery cadence and product management availability. Then limit the number of items in the Discovery phase to maybe half of your development queue. This prevents you from grooming the entire backlog, as you are only allowed to start processing the number of items defined by the WIP limit. If you want more, you need to finish what you started.
Let me explain in a bit more detail: Say you start discussing or prioritizing an item, and WIP limit for “Discovery” is 5. You may now only look at 4 additional items before that first one exits the process. Then it gets difficult: You need to be strict about what the end result of your process can be. My suggestion is that there are only two valid exit states: “Let’s build this next” or “Won’t build in the foreseeable future”. That last one means you (gasp!) delete it.
You see, if you allow “Will build later”, you’re pretty much back to square one. This will make you think long and hard before picking anything that’s not important to you right now, which is kind of the point. You will end up with cases where you start the discovery, and for some reason you have to abandon it without finishing the process. No one will shoot you if you put the item back in the Idea column to be picked up again later, but this should be a rare exception. Luckily we also have the Idea purge policy as suggested above to make sure it goes away eventually.
Congratulations! You have now put a hard limit on the number of items that are constantly being discussed and specified and prioritized up and down. An important point is that the queue used to replenish your team Kanban board or Scrum sprint is also covered by the WIP limit. So if your “Build this next” queue is full, there is no reason to start processing anything else. This helps you make business decisions about what to build as late as possible, which is also a good thing. The later you decide, the more information you are likely to have about what is the right thing to build.
A small tip at the end: If emptying the “Build this next”-queue takes so long that you feel the temptation to start re-prioritizing what’s in it, your WIP is likely too high.
That’s it, you’ve now stopped spending precious time on “good ideas” that will never be built — and you have an effective process to help you spend just the right amount of time on the stuff that will.
What do you think? Could this work for you? See any problems with the approach? I’d love to hear your comments!
