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
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
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
developbranches 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?
- 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.