Recently, we've noticed that some tasks on our boards get stuck during client approval. For instance, a task might take us 10 days from scratch, but then it could linger in the 'Review' column for the same amount of time or even longer. We decided to delve into the issue, leading us to significantly overhaul our workflow.
What our previous workflow was like
Our entire company’s production is built on Kanban. More precisely, it's based on IMAGABAN. This is our interpretation of the Kanban method. We've already extensively discussed it, so I won't dwell on this topic for long. I'll only describe one characteristic of our approach — we divide all the work into three services:
1. Management.
2. Requirements.
3. Features.
1. Management.
2. Requirements.
3. Features.
For each service, there is a separate Kanban board with its set of tasks and workflow. On the Management board, we handle tasks related to maintaining the Requirements and Features services. On the Features board, we focus on development-related tasks. However, our interest lies in the Requirements board. Primarily, designers and analysts work on it.
On the Requirements board, we handle tasks related to requirements. Before a task proceeds to development, it must be fully prepared. It will only appear in the 'To do' column on the Features board when we have a detailed specification, design, and content—all of which have been approved by the client.
Here's how it looks:
On the Requirements board, there are five columns: To do, In progress, Validation, Client Acceptance, Done.
Every new production task is initiated by the manager on the Requirements board. It initially appears in the To do column and then progresses through the remaining columns. Our departments also have their own boards. For instance, the design and planning department or the development department have their respective boards. This means the heads of these departments can view tasks assigned to their employees across all projects simultaneously and can manage their workload.
Tasks stayed in the review stage for a long time, which was frustrating
We noticed the problem thanks to metrics. Each task on the Requirements board followed the standard path from 'To do' to 'Done.' We tracked the Cycle Time (the time it takes for a task to go through the entire Kanban board). Soon, we observed a pattern: tasks reached 'Client Acceptance' and lingered there for an extended period.
- Let's say we could spend 10 working days on developing a page interface. However, later in the column where the client approves it, this task would sit for 20–30 days or even longer. While the other columns cleared quickly, tasks accumulated here. Heads of departments noticed this and raised questions. Clearly, something wasn't right.
This situation occurred across various projects and among different specialists, indicating that the problem was evidently widespread. After thoroughly analyzing everything, we understood what was happening. During the Client Acceptance stage, the team received feedback from the client. While these were being addressed, the task remained in that column — according to Kanban rules, moving it backward wasn’t permitted. However, essentially, throughout this time, it followed the same path as before — passing through To do, In progress, and Validation.
Across all boards—the project board and the workshop boards—we witnessed a backlog of tasks
This situation was unsatisfactory for us. The problem lies in our inability to effectively prioritize tasks. For instance, we presented one task to the client for the first time today, while another was already on its third iteration. When both tasks are in the same column, they share equal priority, although it would be better to complete the one that holds greater value due to accumulated work.
We changed the workflow to prevent tasks from slipping through the cracks
To bring tasks out of the blind spot, we visualized the process of handling edits. To do this, we introduced additional swimlanes on the Kanban board. Each of these replicated the main workflow: To do, In progress, Validation, and Client Acceptance. Essentially, the task was returned to To do, but within a different swimlane.
All iterations of edits are now placed within separate lanes—swimlanes
For instance, when the client mentions that the task is generally fine but has a couple of comments, we agree to address the first iteration of these comments, and the task is moved to the To do column of a new swimlane. Previously, the task would have remained in the Client Acceptance column. As there might be several iterations, the task could have lingered there for a long time.
Typically, for each board, we add two additional swimlanes: one for the first iteration of comments and another for the second and subsequent iterations. Our standard agreement accounts for two rounds of comments. Quite often, this suffices for the client's approval of the task.
Thanks to the swimlanes, we can see the actual stage at which the task currently resides
Recently, as an experiment, we added a third swimlane — Post-Production. At the moment, we're not certain if we'll keep it in the future. This lane typically includes tasks and artifacts that we refine for internal purposes. Even after a task has been accepted by the clients, there are instances when it requires further adjustments.
- For instance, the design itself might be approved, but the designer needs to illustrate additional states, prepare layouts for handover to the development team, or add minor elements to the UI kit. These tasks need to be done regardless. However, we prefer not to create separate tasks for these since they essentially relate to the same task.
It's easiest to explain the new workflow through design tasks. However, in reality, we apply it to every artifact on the Requirements board: technical specifications, analytical data, UX and UI design tasks—everywhere there might be multiple iterations of comments or adjustments needed.
This is a simple solution that, nevertheless, improved resource management.
What were the concerns, and how did we address them?
Concern #1
There are familiar stages visualizing the work: Open, In progress, and Done. Each of these stages has numerous statuses. Each task is unique, always undergoing changes. Why do we need additional swimlanes?
In our case, it was crucial to alleviate the workload specifically on the Client Acceptance column. This way, we could gain a clearer picture of our tasks: what's currently under review, what has been sent back for revisions, which tasks are nearing completion, and which ones are undergoing initial review by the client. Artifact preparation took a week, while acceptance took a month. Clearly, something was off; it was better to break down this stage into several other stages.
In our case, it was crucial to alleviate the workload specifically on the Client Acceptance column. This way, we could gain a clearer picture of our tasks: what's currently under review, what has been sent back for revisions, which tasks are nearing completion, and which ones are undergoing initial review by the client. Artifact preparation took a week, while acceptance took a month. Clearly, something was off; it was better to break down this stage into several other stages.
Concern #2
Instead of swimlanes, why not use additional columns?
This approach didn’t suit us. A couple of new columns wouldn’t provide enough clarity in our workflow. All it did was overcrowd the board and complicate the workflow. Additionally, when dealing with iterations, tasks essentially repeat the path they've previously taken, making the solution involving additional swimlanes appear more elegant.
This approach didn’t suit us. A couple of new columns wouldn’t provide enough clarity in our workflow. All it did was overcrowd the board and complicate the workflow. Additionally, when dealing with iterations, tasks essentially repeat the path they've previously taken, making the solution involving additional swimlanes appear more elegant.
Why we’re proud of ourselves
1. At first glance, this solution might seem to change little. However, in reality, we've managed to simplify and optimize the work for the design department. Now, it's easier for the team to manage resources and priorities. Previously, just having a board wasn't sufficient for this level of efficiency.
- When the department head can see the stage of a task, they can authorize a specialist to start working on it immediately or later. For instance, in one project, the requirements document might already be at the final stage, while in another, the team hasn't yet begun. A quick look at the board indicates which task has a higher priority. Previously, this would have required discussions with the manager of each project.
2. The new workflow organizes work within the projects themselves. Now, each iteration of edits has a clear starting point, and some adjustments can be made. However, if the manager moves a task to “To do” in the next swimlane, it signifies that both the manager and the client understand it as a new iteration.
3. The new system helps in better controlling the workshop’s tasks. With increased transparency in the process, we can now see where tasks get stuck. If a particular design has reached the second iteration of edits, the workshop supervisor understands the need to focus on it. They might consider rotating and assigning a different person to handle this task.
4. Such meticulousness is particularly beneficial in fixed-price projects, where addressing feedback takes more time than the initial iteration. It's crucial for the client to consistently understand the stage we're at. Moreover, additional metric monitoring can help pinpoint bottlenecks and streamline the process overall.
4. Such meticulousness is particularly beneficial in fixed-price projects, where addressing feedback takes more time than the initial iteration. It's crucial for the client to consistently understand the stage we're at. Moreover, additional metric monitoring can help pinpoint bottlenecks and streamline the process overall.
