What should a Kanban board visualize?

  • Kanban prescribes to visualize work and the process it goes through. But what exactly should be visualized? (This is a general question about Kanban board design.)

    For example, should we visualize:

    • all participants that are currently working on an item
      • a tester and a developer collaborating during the testing phase, or
      • a developer and a code reviewers collaborating on an Pull/Merge Request
    • a work that is external to the project
      • external team ask us to review their chages because they may affect in some way our functionality)
    • a team member is helping another team member with their item (instead of working on his own item)
    • original estimate
    • actual spent time
    • meetings
    • etc

    All these information could help better understand the flow of work and see easier the inefficiencies and areas of possible improvements.

    On the other hand, some information may have been proven to be counterproductive or not worth being visualized.

  • TL;DR

    While there can be circumstances where you need the level of granularity you're proposing, in most cases it's likely to be a symptom of command-and-control management styles and an outgrowth of the 100% utilization fallacy.

    Kanban should generally be tracking significant state transitions at the product level, not attempting to prescribe procedures in visual form. The latter is a form of micromanagement that's antithetical to Kanban's objectives.

    Right-Size Granularity to Reduce Waste

    Kanban is a framework that is not overly prescriptive. At heart, Kanban functions best as a rate-limiting leaky bucket system. Managing queue sizes by preventing an excess of pending requests from entering the process is a core objective of most implementations of the framework.

    "Visualizing the work" is a key element of David Anderson's Kanban Method, rather than a formal requirement for Kanban in general. Like other lean approaches, though, it's not highly prescriptive.

    Kanban, like most agile systems, is all about right-sizing the granularity of work to optimize for flow. So, there's no canonical answer to your question except to say that work (and the work states represented by columns) should be:

    1. as granular as possible, because smaller items increase flow; but also
    2. as coarse as practical, because micromanagement increases process overhead and creates inefficiencies.

    With Kanban, an overly-granular approach to process such as the one outlined in your post is likely a symptom of top-down management practices rather than an empirical, continuous-improvement approach to increase flow or reduce queue sizes and cycle times. You probably shouldn't do that, but your mileage may vary.

    You need to work with your teams and organizations to identify bottlenecks, gating processes, and other forms of waste in your cumulative flow. Then actively work to remove them. Creating process overhead for its own sake is actually just another form of muda, and should be treated as waste to be eliminated from your process.

Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2