2.5D Backlog

Since we already are visualizing the flow, defined WIP’s, established some measurements and agreed what “done” means, it’s time to use models to suggest improvement opportunities.

So my first suggestion is to use Cost-Benefit / Effort-Value models as improvement opportunity to visualize backlog. First little background; we changed one A3 sized whiteboard to larger model in one room. I started to think what to do it or should I consider it as waste. After hard thinking and 2 cups of coffee I had the Illumination. Let’s put there some axis and have at least 2D visualization of something. After yet another thinking session it finally came to me; The Backlog. So we got this.

2.5D Backlog

X-axis shows business value of the task. Y-axis is combination of known effort/cost and technical risks involved to task. There is no defined scale or values to axis. Task notes are just put to board relatively to each other. Now we can see Easy-Wins from lower right portion of backlog to be priority candidates for selection. Not forgetting that Technical-Risks with great business value on top-right of chart should start as early as possible. But actual selection criteria can vary from project to project or even during the project.

Everybody is allowed to change position of notes. Fortunately our customer proxies do not touch on cost dimension. Currently project manager does check and pull the tasks he wants to the “selected”-column on Kanban board, but on long run I think we can get a rid of the “selected”-column all together and let the team to do decisions themselves. Project Manager just checks and realigns notes taking special care of tasks with hard deadline or where value has dependency to time.

The colors represent different types of tasks. That's the "point five" dimension. We use red-defect, yellow-improvement of current feature, blue-complete new feature.

There have been some discussions lately if estimation is even needed in Agile/Lean development? (we do estimations - at least for some tasks…) Our 2.5D backlog is more team visualization tool rather than formal estimation, but I think it can replace formal estimation at least for some domains.

We are also in process to create simple tools to improve our measurement part of Kanban. “Stay tuned”…