When reading this Kill Your To-Do List blog post, I thought that managing personal to-do list can be similar to product backlog management. Not in the part that you should totally kill your product backlog, but in the “one thing at a time” part. This is by no means a new thought. E.g. Mary Poppendieck was heard saying that product backlog should be eliminated.
So, as in to-do lists, there’s no point in nurturing and moving product backlog items back and forth. In this case, a lot depends on what is your definition and understanding of product backlog. I’d say backlog is an environment in which a product grows and exists but not a set of components that should be implemented for sure. Looking further into, what kind of environment is it? Backlog might be a repository of all the slightest shades of ideas that have a very vague chance to be implemented. A chaotic heap. This heap can hardly be called a “backlog” but rather a by-product of brainstorming. OR a product backlog might represent a careful selection of user stories that will be implemented for sure.
Both of these options, as often is the case, have the optimal state somewhere in between. In our production workflow, we’re now using several buffers – the first layer is raw Requests and Ideas (coming from our HelpDesk, or from the PO, or from the team). The second layer is Product Backlog with User Stories (Requests and Ideas are now groomed and converted to User Stories by Product Owner who decides that some time these will be implemented for sure – based on how many people requested this feature, based on current product development strategy etc.). The third layer is Planned state for User Stories in Kanban board.
Here’s a quick graphical representation of this product backlog upward funnel:
That’s how User Stories lifecycle looks on Kanban board, from Planned state on:
Backlog is not seen on Kanban board. When done with their current user stories, developers pull new user stories from Planned state.
Previously, when we worked with iterations before switching to Kanban, there was no buffer between inception and implementation – so time-boxed releases and iterations have been planned directly from the backlog. With Kanban, the buffering is done by moving stories to Planned state and prioritizing them.
I’d say that planning with iterations provides less flexibility than planning with Kanban. As you drop user stories to time-boxed iterations, you commit to implementing all of them within a given period of time. Kanban is way more flexible since user stories can be pulled one-by-one from Planned state and implemented with no time restrictions. I can’t resist citing an analogy here: it’s the same as moving with the smallest possible steps to posture yourself before hitting the ball in tennis. With large steps, you do not have flexibility. With small steps – you’re very agile and flexible to position yourself for the perfect shot.
So, the buffered Planned state in Kanban is like this breaking down into small steps, instead of taking one giant leap and committing to the whole pack of user stories in iteration.
That’s the way it goes for us. You’re better off moving by small steps, taking it one-by-one (this brings us back to the inspiration blog post reference in the beginning :) than with giant leaps.