_edited.png){kind=logo}
If anyone knows anything about Kanban, they know about the board. The giant grid with value stream stages at the top and sticky notes scattered across it is the iconic symbol of Kanban systems.
Interestingly, there are no requirements in Kanban that your board needs to look like this. It doesn’t even have to be a board! As the Kanban Guide tells us:
“The visualization of the DoW (Definition of Workflow) is called a Kanban board. Making at least the minimum elements of DoW transparent on the Kanban board is essential to processing knowledge that informs optimal workflow operation and facilitates continuous process improvement.
There are no specific guidelines for how a visualization should look as long as it encompasses the shared understanding of how value gets delivered.”
So, Kanban boards might look like round targets that converge on a bullseye. They might look like a winding snake that drops items off into individual queues. They might be a 3D VR environment where you slice your work items apart with lightsabers. The visualization can be anything that effectively presents the shared understanding of how value is delivered.
But for all the flexibility we have in visualization, we have to capture the minimum elements of the Definition of Workflow. Let’s look at these six elements from the Kanban Guide and see what you might be missing from your Kanban board.
1. The individual units of value that are moving through the workflow
These are typically represented by the “cards” on the Kanban board. What are these units of value? You define them. For my software development teams, these are typically user stories. But whatever you pick, your board needs to show them.
2. When a work item “starts” and when it “finishes”
At some point, when your team pulls an item to start work on it, the clock starts ticking. When is that point? When are items considered finished? Are those visualized somehow on your board?
One visualization I saw that I liked was a bicycle icon to mark the column that counted as “Start” and a stop sign icon to mark the column that counted as “Finished.” Your board might also designate more than one “Start” and “Finish” depending on which portions of production you’d like to measure. For example, you might have a start and a finish that covers the entire production from “Requested” to “In Production” because that’s the span your customers care about. But you also might have a start and a finish from “Development - Doing” to “Testing - Done” because that span is more useful to your DevOps Manager.
3. The states a work item flows through
These are typically the “columns” on your Kanban board. What are the stages of transformation a work item moves through until it is a completed item?
Keep in mind these stages are defined from the perspective of a work item being worked on. The columns represent the stage a work item is in, not necessarily the roles involved or the specific kinds of work being done by those roles.
For example, you might have a column called “Requirements - Doing,” but your QA team might be writing their test scripts in that stage and your developers might be breaking things into tasks. Everyone might have something to do to move a work item from “Requirements - Doing” into “Requirements - Done.”
4. WIP controls
The way most people are familiar with visualizing this is by placing numerical WIP limits on the tops of either columns, groups of columns, or the entire production flow (my personal favorite).
But Kanban does not mandate how you control your WIP. “Total number of items” works for a lot of teams, but you might decide instead to do it by item type—only a certain number of user stories and a certain number of bugs at any given time. Or you might have no numerical limits and just allow team members to call a freeze on pulling new work when the team is getting overburdened. I’m not saying all of those are great ideas, but you can find the WIP control mechanism that works best for you.
Whatever your WIP control definition is, though, it needs to be represented on the board somehow.
5. Explicit policies on how items move from start to finish
Everyone participating in your Kanban system (Kanbaneers?) needs to have a clear understanding of how items enter your system, move through the system, and leave the system.
How often do you pull in new work? Are you ever allowed to exceed WIP limits? How do you know requirements are done and an item is ready for coding? What do you do about blocked items? What amount of testing should developers have done before they signal QA that an item is ready for them to look at?
It can save your team so much time and so much money on therapy to come to policy decisions about those questions and questions like them.
But what good are those policies if they’re not visible to all? Your board needs to have them visible in some form or fashion, whether they’re printed out sheets taped to your physical board or a notes field on your board columns in your electronic tool.
6. The Service Level Expectation (SLE)
How long should it take for a work item to flow from start to finish?
Not only is this valuable information for your team to detect potential workflow problems early—it’s valuable for many in your organization to plan and set expectations. And like much of the information that a Kanban board radiates, it can answer a lot of repetitive questions simply by checking the board.
An SLE simply presents that information. It can be as simple as a notecard that reads, “An item should take 12 days to complete 85% of the time.”
Keep in mind, your SLE comes from your actual data of how long items are taking; it does not represent your hopes or some kind of speed commitment to the organization. It is merely an indicator of how long your work items are actually taking.
Those are the minimum elements of a Definition of Workflow that should be visualized on your Kanban board. Which ones do YOU need to add?