3D Backlog Management
Managing or prioritizing backlog and re-prioritizing work in progress are some of those activities that usually make a product owner very busy. This is not a breaking news, obviously. Product Owners have lots of things to consider as they:
1. keep some work in the backlog (as unsorted as a pile of chopped wood);
2. sign off some work to go into production;
3. re-prioritize work that is already in progress.
At times, the boundaries between a pure production flow (Work In Progress, as in Kanban) and backlog are quite blurred. Some items might stall, if it turns out that they need to be re-prioritized and/or returned back to “the pile of chopped wood”. You might wonder, as a product owner, or a project manager, when is it OK to go with the 2D map which plots work against the In Progress states (as in the classical Kanban board), or when you might need a 3D concept map to balance your decisions against multiple priorities? Are there any workarounds you can use for a 2D map to make it work as a 3D one, if there are more things to consider than merely putting work through the production flow?
Some of you might be familiar with the concept of story maps vs. process maps, but I’m using a bit different perspective here. A part of it is covered by the story map concept of “a walking skeleton”, but what I’m trying to highlight is the speed and convenience with the 1–2–3 of a product owner’s actions.
Here’s a 2D Kanban board, where Planned is some prioritized, ready to go to In Progress work:
You might need to introduce a yet another buffer for the sorted out Planned state. That’s when you most probably add the Open state:
Backlog -> Open -> Planned -> Work In Progress -> Done
The Open and Planned states are not the sequential production states. The Planned state, actually, represents the result of applying some other 3rd dimension, e.g. some set of business or any other priorities. As a product owner, you need to sift the work through many decision criteria, bouncing it between Open and Planned as often as needed. That’s what we call “grooming the backlog”.
If you operate within this 2D environment, on a physical or electronic Kanban board, you might use tags, or colors for the cards, or add more non-production states which are essentially priorities (as Open — Planned states).
Now take a look at this visual. It’s a little bit different from what is considered a story map concept, as I’m using another set of coordinates, where X-axis is work, Y-axis is progress, the X-Y plane is any work in progress AND Z-axis is any other 3rd dimension, or lens, through which you filter the backlog or work in progress. The red lines in the Z-plane against the X-Y plane represent those various influences, or the filtering criteria.
If you’re using some tool to switch and rotate the criteria on the Z-axis fast, you’re much better off grooming your backlog, prioritizing work, and tracking work in progress. I’ve mentioned some workarounds, such as using tags, or colors for cards, or introducing the states that are not actually “production” but rather “prioritizing” states. Another traditional technique is prioritizing work in lists, not on a board. But all those practices are quite limiting. They don’t provide enough versatility.
The arrows on the Z-axis plane, as shown above, are essentially swimlanes, if you look closer, and they add another layer of flexibility to backlog management. If 2D workarounds are limiting, or your current backlog management practice does not include using a swimlane, you might want to consider adding it to your work process, as a product owner. It will work exactly as on the visual above: the rapidly switchable Z-axis shafts (swimlanes) that highlight certain backlog items and work in progress.
… and, well, a word is out that some teams have dropped the practice of backlog grooming altogether. I’ve been thinking along these lines for quite some time as well, and wouldn’t this be one of those cases of which I wrote earlier that you just have to wait until the time is right to speak up?
Rest assured, I’m going to put some product management myths that have outlived themselves under scrutiny. Not for the sake of disruption. That’s the way everything in life goes: some things that used to make sense might become dysfunctional, or even counterproductive with time. And, the earlier we identify such myths, the better off we are emerging on the other side, in the long run.
Stay tuned :)
Related:
Product Development: Drive or Hitchhike?
This story is based on an earlier article.
