3-D Backlog Management
3-D Backlog Management
Join the DZone community and get the full member experience.Join For Free
Get the fastest log management and analysis with Graylog open source or enterprise edition free up to 5GB per day
Managing or prioritizing the backlog, re-prioritizing works in progress — these activities make up the most of a product owner’s work. That’s not breaking news, obviously. Product owners have lots of things to consider as they:
1. Keep some work in the backlog (as unsorted as a heap of wooden logs)
2. Sign off on 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 a backlog are quite blurred. Some items might stall, as it turns out that they need to be re-prioritized and/or returned back to the “heap of logs”. You might wonder, as a product owner, or a project manager, when it is OK to go with the 2-D map that plots work against in-progress states (like in the classical Kanban board), or when you need a 3-D concept map to balance your decisions against multiple priorities. Are there any workarounds you can use for a 2-D map to make it work in 3-D, when there are more things to consider than merely putting work through production flow?
Some of you might be familiar with the concept of story maps vs. process maps, but I’m using a slightly different perspective. A part of it is covered by the story map concept of the “walking skeleton”, but what I’m trying to highlight is the speed and convenience with the three product owner actions above.
Here’s a 2-D Kanban board, where "Planned" is some prioritized, “ready to go to In Progress” work:
You might need to introduce yet another buffer for the sorted out Planned state. That’s when you most probably want to 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 is a product of applying some other 3-D dimension -- some set of business or any other priorities. As a product owner, you need to sift the work through many deciding criteria, bouncing it between Open and Planned as often as needed. That’s what we call “grooming the backlog“.
If you operate within this 2-D environment, on a physical or electronic Kanban board, you might use tags, 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 the X axis is work, the Y axis is progress, the X-Y plane is any work in progress and the Z axis is any other 3-D 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 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 works in progress. I’ve mentioned some workarounds, such as using tags, introducing the states that are not actually “production” but rather “prioritizing” states: colors for cards. 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 lines of the Z axis are essentially swim lanes, if you look closer, and flexibility with swim lanes is a huge thing. If 2-D workarounds are limiting, or your current backlog management tools do not give you enough freedom with swim lanes, we have an unbelievably flexible 3-D backlog management experience in store for you, coming soon in a newer version of our tool. It will work exactly as on the visual above: rapidly switchable Z axis influences (swim lanes) that highlight certain backlog items and work in progress.
Published at DZone with permission of Olga Kouzina , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.