Show all posts
3 years ago

Take 5 Visual 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 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.

Kanban flow

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 the first and foremost report.  It shows how work "accumulates in flow" (hence the name) with time.

cumulative flow diagram

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.

cycle time by month

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:

Process Control Chart

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:

Visual History

visual history flow

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:

Cycle Time Distribution

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 🙂

  • dingclancy

    TP is awesome but still waiting on Team-specific Cumulative Flow Diagrams. Hoping that you add it soon!

  • indigo777

    .. at some point 🙂

  • Niel Modi

    Kanban method encourages small continuous, incremental and evolutionary changes that stick. When teams have a shared understanding of theories about work, workflow, process, and risk, they are more likely to be able to build a shared comprehension of a problem and suggest improvement actions which can be agreed by consensus.

  • Udo Carls

    Just came across this reporting write-up – nice overview. The discussion of the cycle time diagram is at least misleading though, for it does not show, as you claim, the number of stories / bugs completed per month, but the average number of days a story spent in development. – which dramatically alters the meaning of the data. 34,5 for November, for instance, shows that things were going rather slow that (and the previous) month, not that the team got more done than usual.

  • markeneumann

    Just discovered this great report summary. What tool did you use to generate these? JIRA? Excel?

  • Michael Dubakov

    Targetprocess –

  • markeneumann

    nice! so many new tools, hard to keep up.

  • tedmyoung

    I’m confused by the “Cycle Time by Month” chart. The y-axis is “days”, which I interpret to mean that the (average? median?) cycle time per story is that many days. That would mean that stories in November took the longest to implement. However, that’s not what the text says, so I must be interpreting the chart incorrectly. What does the y-axis mean, then?

Get started
for free

Sync up your teams with a visual project management tool that adapts to your organization and gives you transparency across different projects and departments.
Visualize every step of the way.

By clicking Continue you agree to our Terms of service and Privacy policy