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 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 you will see now how those visual reports can be of help.
Cumulative Flow Diagram
…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 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, this means that the backlog needs good grooming (maybe some part of it shouldn’t be in the ToDo state, but in some other pre-production state, similarly to what I’ve described in my recent 3D Backlog Management post). 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 and would make no sense.
CFD reminds me of the tectonic layers and the Earth formation process. An easy way to memorize the logic of this 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, this means 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, as it covers the time that work seats 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 fast.
The cycle time report above shows an abrupt spike of completed user stories in November. This probably means that the team worked full gear to get as much as possible done for some major milestone. Later on it 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, it means that all is 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”, like 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 the reasons for its oddity. This is our next report:
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, 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 just diagnose how things were 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 is powered by the historical data from lead and cycle time reports:
You can read more about some practical uses for lead and cycle time distribution chart here.
If you need those reports for your work, feel free to look into the peephole on the right :)