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 – I would not expect to see the Chef’s tasks on the Kanban Board (i.e., “slice the prime rib,” “bake the potato”) because 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 – I would not expect to see development tasks on the Kanban Board (i.e., “test the new form,” “update the data table,” “refactor function foo()”) because those activities 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 Product Backlog Items 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 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 “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.
If what I’ve described does not match what you’re currently doing, or if you have questions, please comment below.