Important to remember
Kanban Boards make visible the flow of value — items of value. In a Scrum context, those items are Product Backlog Items, not the decomposed tasks of the Sprint Backlog.
This point is often misunderstood or overlooked, so I’ll explain with multiple analogies:
If in a restaurant, the Kanban Board would show the progress of diners’ experience. Columns on a Kanban Board might have labels like Waiting to be seated, Ordered, Main course, Dessert, Paid, and Table cleared. The Kanban system in this case would be optimized for the flow of meals for customers. The cycle we should want to measure starts when a customer enters our restaurant and ends when they have finished their dining experience.
I wouldn’t expect to see the chef’s tasks on the Kanban Board (e.g., “slice the prime rib,” “bake the potato”). Those task-level chores are not, in and of themselves, valuable to the customer.
If in software development, columns on a Kanban Board might have labels like Discovery, Implementation, Deployed, In Production, Done. The Kanban system in this case would be optimized for the flow of Product Backlog Items (PBIs).
I wouldn’t expect to see development tasks (i.e., Sprint Backlog Items) on the Kanban Board (e.g., “test the new form,” “update the data table,” “refactor function foo()”). Those task-level chores and technical procedures are not, in and of themselves, valuable to the stakeholders.
Many teams post their Sprint Backlog tasks on a board with columns like To Do, Doing, and Done. The items on that board are the technical procedures, chores, steps, recipes, and activities that developers will conduct to convert PBIs into usable functionality.
That’s not a Kanban Board. I’m not saying it isn’t helpful — it’s a sensible way to track tasks. But to be a Kanban Board, two conditions must be met:
The right level of abstraction.
The items on a Kanban Board are meaningful to both the stakeholders and the team — they represent recognizable value from a customer’s/user’s perspective.
Like in the restaurant analogy, the Kanban Board would visualize the flow of a customer’s meal (e.g., “Eggs Benedict”) whereas the Sprint Backlog would be the chef’s plan to cook and deliver that meal (e.g., “mix the Hollandaise” and “toast the English muffin” and “poach the eggs.”)
Explicit WIP limits.
A Kanban Board imposes limits on Work In Progress. The people involved in the flow of work have made explicit agreements to constrain how much can be in progress at any one time.
In the visual below (a software dev example), the Kanban Board shows the Product Backlog Items that are currently between Selected for Development and Done. These items are certainly in focus throughout the current Sprint, and one or more of them may have been started in previous Sprints. (A Scrum team should want to minimize the number of PBIs carried over from one Sprint to the next, but it’s not uncommon.)
And on a separate board, the same team can visualize the flow of their Sprint Backlog tasks from To do to Done. (Tasks of the Sprint Backlog are decomposed from the PBIs selected for the Sprint — they are the chores and technical procedures that derive from PBIs.)
The illustration above is available as a Mural.co template I created to help my clients understand the necessary separation between the Sprint Backlog tasks and the Product Backlog Kanban Board.
Why Does This Matter?
It matters that you measure the right things.
If a team measures the Cycle Time of Sprint Backlog tasks, they may observe the illusion of progress while hiding bottlenecks and delays. A team may appear busy, moving Sprint Backlog tasks from Doing to Done, while the actual delivery of value to customers (the PBIs) could be slow or uneven. By visualizing and limiting the flow of Product Backlog Items (the items that truly matter to stakeholders) Kanban exposes real constraints and encourages the team to optimize for outcomes rather than activity.
When blending the ideas of Kanban with Scrum, you should want to measure the Cycle Time of value-creating Product Backlog Items, not the tasks of the Sprint Backlog
