DataViz 101: 5 Reports for Kanban
In this installment of the dataviz series, I will tell about some visual reports that might be of interest for Kanban practitioners.
We all know Kanban as a process that has a production flow visualized on a board. The to-dos (or work) get started in Backlog (or in the Planned or Open state), then they get to In Progress (or to any other variety thereof), and end up in Done.
So, yes, we all know about Kanban, but some of you might be less familiar with the reports that go along with it. If Scrum comes with only 2 visual reports (the iteration and release burn down charts), Kanban has several of them, and here I’ll show how these visual reports can be of help.
Cumulative Flow Diagram (CFD)
…is the first and foremost report. It shows how work “accumulates in flow” (hence the name) with time.
What can you get out of this visual? First, the correlation between the ToDo (or Planned) work, the In Progress work, and the Done work broken down by weeks. The diagnosis for the team that has such a sleek CFD is nothing short of a utopian, by the way. The light blue layer is ToDo, the green layer is Done, the beige layer in the middle is Work In Progress. You can see that if the blue To Do layer gets too thick, the backlog would need some good grooming (maybe some part of it shouldn’t be in the ToDo state, but in some other pre-production state, similarly to what’s described in one of my earlier posts). If the beige In Progress layer gets too thick, someone has to set reasonable Work In Progress limits. Well, the only layer of those three that looks good when it’s fat is the green one. A point to note about CFDs: they work well if you want the bottomline diagnostics report for only 3 states. If your Kanban process includes some sub-varieties of them, the report would get too clogged.
CFD reminds me of the tectonic layers and of the Earth’s formation process. An easy way to memorize the logic of the report would be this: the more rugged the outline of the layers is, the more turbulent the process, the more bottlenecks it has. Ideally, this report would have all the surfaces even, where the blue layer (the ocean surface) remains serene and almost untouched, and this means that just a few to do’s are added; the seabed layer (the work in progress) is reasonably thin, and the solid baseline layer of the Done work (the Earth crust) is getting thicker and thicker (but that’s utopian…).
Lead and Cycle Time Report
… is another visual report that is so vital for Kanban. Actually, the lead time report is not that helpful for software product development, since it covers the time that the work sits in pre-production state (read, in any of the backlog states), whereas the cycle time is a pure “work in progress” span. The lead time would have more meaning for hardware production, where people look at it as the measure of how long the storage space is occupied with the parts, for instance, and they need to adjust their process accordingly. For software development, no warehouses and storage spaces are needed, that’s why only the cycle time report would matter *unless the work items are requests that come from customers. In this case, a short lead time would suggest that those requests are implemented/resolved quickly.
The cycle time report above shows an abrupt spike of completed user stories in November. The team must have worked full gear to get as much as possible done for some major milestone. Later on they went back to a rather even development flow. Besides, the correlation between completed stories and bugs is supposed to show, ideally, if it was a quality work. April looks very well, as it had 12.4 user stories completed with only 3 bugs. You get the idea.
Process Control Chart
… feeds on lead and cycle time reports. It shows if the development process is healthy and under control. Take a look:
If most user stories are scattered around the median line, all’s well with the process, and most of the user stories are done within the average time to complete. You can also identify any “odd sheep”, such as the story that took 34 days to complete, or even 80. At this point, the process control chart has nothing more to say, and we need to click this “odd bubble” to find out more on the reasons for its oddity. Here’s the next report:
Visual History
It indeed uncovers some of the reasons, as you can see from the screen above (the red boxes at the bottom are bugs). This story has been thrown back and forth from state to state (the states are shown on the left), it had a suite of bugs, and not all of them were fixed… what an unfortunate user story.
Lead and Cycle Time Distribution
Finally, there’s one visual report for Kanban that can give a forecast. While all the other reports only diagnose how things have been going in the past, this one predicts how likely it is that some user story will be released in any given amount of days. If we look under the hood, this report must be powered by the historical data from lead and cycle time reports:
I hope this article has provided an overview of some visual reports that are generally used with Kanban in work management.
Related:
Visualization: Understated or Overrated?
This story is based on an earlier article.
