3

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.

3

Kanban's first principle is "Start with what you do now." and iterate from there. So, what you want to visualize is completely up to you, based on what you do today to track data about your work items.

If you have absolutely no current process/ practice regarding something, start somewhere - take a decision as a team that "we will visualize these things on our Kanban board and each ticket". These become your initial "policies" that you can change in the future, depending on how well they work for your team.

Some of the ticket design options suggested by the Kanban University material are shown below -

enter image description here (C) Kanban University (earlier Lean Kanban, Inc.)

These are also suggestions - nothing is 'prescribed' - it is up to your team.

We use Kanban for our product development - and here are things that we visualize -

enter image description here

Of course, different teams can choose to visualize different things on the board and at the card level.

enter image description here

In general, as Todd has mentioned, how granular do you want your board and cards to be depends on what you are trying to track on the board and at the card level - what is important to your team and your stakeholders.

On a couple of items that you have specifically mentioned, here are my thoughts -

  1. Visualizing "external work" - work being done by another team. This assumes that some work on YOUR board is held up (blocked) due to an external dependency. This should be visualized by having a blocker on the card (such as the red blocker on the bottom-right corner of the second image above) - with some description or comment to let team members know why this is blocked.

  2. A team member is helping another team member do their work. This can really happen in multiple ways - and depending on how often this happens, how much of their own time team members are spending working with someone else on THEIR tickets, and how long does it take them to work on others' tickets, etc. If it is very minimal, you could have WIP Limits on your board columns (or individual WIP Limits) to accommodate a person working on multiple tickets at a time (whether they block their own ticket or not - policy item!). If a significant part of a team member's time goes in helping others, then you definitely need explicit policies on how they deal with their own work (block it, move it to a "Waiting" bin, etc.) and how their contribution is recorded on the others' tickets (such as having two people assigned to that ticket while both of them work on it, etc.)

You could also have policies such as "Anything that takes less than 15-30 minutes need not be recorded on the board/ ticket". It depends on how often this happens.

Other than the above, in my opinion, a Kanban board should visualize the following -

  1. WIP Limits on each lane and column
  2. WIP Limit violations if you allow them, and
  3. Card-level flags for Issues, Risks and Blockers
  4. Class of Service associated with tickets (this can be done in multiple ways)
  5. Work-item type

Here are some options on how boards might look - Boards organized by activity type or by teams.

enter image description here

Or, a board organized by class of service shown below. enter image description here

Here is an article on board design that might help you - How granular should my kanban board be?. You may also find other useful resources in our Kanban Guide.

| improve this answer | |
3

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.

| improve this answer | |
1

A Kanban board needs to visualize at least two things.

The columns on the Kanban board visualize the states of work in the workflow. Through this, the workflow or process by which work gets done is visualized, allowing anyone to see how work gets from "not done" to "done". Along with this, most Kanban boards also capture information like work in progress limits (how much work can be in each state) or may have a way to denote work that is being expedited.

The cards on the Kanban board visualize the current state of particular work items. This allows for the development of a pull system. People can see if they are producing output faster than it can be consumed by the downstream processes and adjust their flow, while the people working in downstream processes can see when work is ready for the next steps.

Depending on how you manage your Kanban board, you may optionally indicate the primary actors involved in the work, how long a particular piece of work has been in progress (from the time it was started, from the time it entered its current state, or both), the estimate for the work, or information about the type of work (the project it's associated with, the source of the work, some arbitrary definition of different types of work). This would depend on who is using the Kanban board and how these different stakeholders need to obtain information - the board is an information radiator and should radiate the right information to the right people.

Ultimately, the way to use the Kanban board falls to the people who are actively using it. The only requirements are the visualization of the process or workflow and how work is currently flowing through that process.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.