Kanban board is perfect for feature cards but falls short on subtask cards. How to manage subtasks (assigned to individual workers) on a Kanban board?

Question

We are a small team building webapps for multiple clients in parallel.

We have not been doing full-featured Scrum, but we have "sprints" and per-project boards with the following columns:

• To do
• In progress
• In review
• Done

Such board is perfect for subtasks. A feature in development is a task which requires work from several workers: designer, backend developer and frontend developer. So each worker is assigned a personal subtask and moves the subtask across the board as they make progress.

Such board makes it easy to track the workload of each worker. But this approach is suffering from many problems that Kanban is trying to solve: push-style assignments, micromanagement, lots of unfinished work in progress piling up, useless estimations, etc.

In an attempt to embrace Kanban, we've had a meeting discussing an idea to switch to using a single Kanban board. We came up with the following columns:

• Ready for Concept

  Concept in progress

• Ready for Design

  Design in progress

• Ready for Develpment

  Development in progress

• Ready for Review

  Review in progress

• Deploying

  On dev server

  On staging server

  On production server

After discussing this for a while, we have come to a conclusion that this board is perfect for managing client-centric tasks, i. e. each card must represent a feature. Multiple workers work on each card.

But this board falls short quite miserably for managing subtasks. This is because:

• Feature development lifecycle is not linear, i. e. frontend and backend development development can happen in parallel or in arbitrary order. We want the board to make it visible what exactly is going on at the moment, or whom to ping in order to get their reviews and unblock merging.
• PR reviews may require 👀 of multiple people. Naturally, I want to see on the board which PRs require my attention at the moment.
• Deployment can happen separately for backend and frontend, at least to the dev server.
• We have per-PR preview deployments which allow QAing pending PRs. But frontend and backend PRs are preview-deployed against develop branches of each other. If a feature requires both frontend and backend changes, then it can only be QAed when at least one PR is alerady merged (then the preview deployment of the other PR will reflect the result), or when both PRs are merged (then the dev server will reflect the result).

From a client's perspective, all these details seem to be "implementation details" of the "Development in progress column". If we omit these details from the Kanban board, then the board becomes perfectly consistent and efficient at managing feature cards on general scale, i. e. without going into detail.

The problem is that we want the detail! We are going to use the Kanban board inside the team are not considering to expose the board to our clients, at least so far. Thus, we do want those "implementation details of development in progresss" to be visible on the board. We want to see the subtask cards! But at the same time, we want to embrace all the main principles of Kanban: visibility, pull-style assignments, no micromanagement, WIP limits, focus on horizontal swimlane speed at the cost of not being 100% busy all the time, etc.

So how do we do it? Use two boards in parallel? Create a 2D Kanban board? Embed one board into another? Abandon all hope?

---

Homework:

• Accommodating back-end and front-end tasks in Kanban — same question, but fewer details, no good answers, the author did not follow up on comments
• In Jira Kanban, do we use sub-tasks? — not even scratching the surface
• Best Way to Manage Different Types of Work in one Board? — my best find so far. Provides good food for thought but does not offer a solution.

Answer 1

Being a small team, take one project at a time

You said you want to embrace 'WIP limits' principle of Kanban among others. The reason why Kanban recommends WIP limits is to help the team focus and to minimize context switching. Instead you are flying very far in the opposite direction:

Use two boards in parallel? Create a 2D Kanban board? Embed one board into another?

Assuming that you do find a tool that supports any of these, it will be a context switching nightmare for your small team because you are:

building webapps for multiple clients in parallel

My recommendation is that you should, first and foremost, apply the 'WIP limits' to the number of projects in progress at a time. One of the key requirements for this is to train your dev team to be more cross-functional. May be getting to only one project at a time is not achievable in practice. But it is worth working in that direction.

When a dev team member has completed whatever they are working on, my guideline for them is to first check whether they can help another team member to complete their work already in progress. Only if that is not at all possible, they should bring new work to 'In Progress' status.

Similarly you should ask the dev team to see what they can do to complete the project already in progress instead of bringing more projects into the 'In Progress' pool. Every new project you add to this pool exponentially increases the context switching productivity hit.