Product Backlog: Steps vs. Leaps
By: Olga Kouzina
Tags: Software Development, Kanban, Startup, Product Management, Agile

As I was reading a post titled “Kill Your To-Do List”, it occurred to me that managing a personal to-do list can be similar to managing a product backlog, in a way. Not in the part where you are supposed to totally kill your product backlog, but in the “one thing at a time” part. This is by no means a new idea; I just feel that it bears revisiting.

So, as with to-do lists, it seems like there’s no point in grooming and moving product backlog items back and forth, right? Still, the answer wouldn’t be an unequivocal “yes”. A lot will depend on how you define a product backlog. We might say that a 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, what kind of an environment would that be? A backlog might represent a repository of all the slightest shades of ideas that have a very vague chance of being implemented. A chaotic heap. This heap can hardly be called a “backlog” but rather a by-product of brainstorming, or a product owner’s/manager’s think pad. OR, a product backlog might represent a careful selection of user stories that are meant to be implemented for sure.

All of these options, as often is the case, intersect somewhere in between; and these various definitions/versions of backlog can keep living peacefully together for tracking/reporting purposes. To back my point, I will briefly describe how the backlog management process was set at a company where I worked before:

In our production workflow, we’d use several buffers: the first layer would’ve been made of the “raw” Requests and Ideas coming from the help desk, or from the product owner, or from the team. The second layer was called “a Product Backlog with User Stories”, where Requests and Ideas would’ve been groomed and converted to User Stories by Product Owner who’d decide that these were to be implemented for sure, after a meticulous prioritization. (As for prioritization, I hope to write on that in-depth some other time.) The third layer would have been represented by the Planned state for User Stories on Kanban board.

Here’s how a quick graphical representation of this product backlog upward funnel looks:

And that’s how the User Stories lifecycle would continue on a Kanban board, from the Planned state on (you might want to note the Planned and In Progress states highlighted in red, and just skip the rest):

The Backlog was not to be seen on the Kanban board. When done with the work, the developers would pull new user stories from the Planned state.

Previously, prior to switching to Kanban, we had worked in sprints/iterations, and there was no buffer between the inception and the implementation, since time-boxed releases and iterations had been planned right from the backlog. With Kanban, the buffering would’ve been done by moving stories to the Planned state and by prioritizing them.

I’d say that planning with iterations provided less flexibility than planning with Kanban. With user stories stacked in time-boxed iterations, we had to commit to implementing all of them within a given period of time. Kanban seemed to be more flexible since user stories were to be pulled one-by-one from the Planned state and implemented with no time restrictions. I can’t resist citing an analogy here: going with Kanban, in this case, reminds me of moving with the smallest possible steps to approach a ball in tennis. With the large steps, there’s no flexibility. With the small steps, you stand a far better chance to position yourself well for the perfect shot. As per this analogy, the buffered Planned state in Kanban provides the same flexibility as breaking down into the small steps in tennis would vs. taking one giant leap and committing to the whole pack of user stories in iteration.

Just… ponder this. Would you be better off by moving in small one-by-one steps — which brings us back to the blog post that provided an inspiration for this story 🙂 — or are there some compelling reasons to commit to many to-do’s in one giant leap?

Related:

Product Development: Drive or Hitchhike?

Featuritis and Vulnerable Visions

3D Backlog Management

One Product Owner Is Not Enough