Introduction
In 2021, I worked as a Product Manager at a technical company, and have been implementing Kanban in my team for the past three years. Kanban’s principles and practical tools aligned well with our team's needs, providing a structured yet flexible approach to managing work. This journey led me to deepen my expertise by earning professional certifications from Kanban University, including Kanban System Design (KMPI) and Kanban Management Professional. In this article, I share a real-world case study of how we successfully applied Kanban to improve our team's efficiency.
About Team
My team at that moment handled the licensing of all company’s products and provided personal accounts to partners and retail users. We processed daily data reports from 360,000 servers and managed around 12 microservices. Our development stack was primarily Java and Python.
The team consisted of a product manager, a team lead, two QA engineers, four developers, and a DevOps engineer. We also had a dedicated support engineer from the support department.
The Challenge
When I joined the team in 2018, they were following Scrum, but it no longer met their needs, and they were eager to explore Kanban. A new team lead had just stepped into the role, and 70% of the team members were new, leading to instability, loss of context, and a lack of explicit policies. Task management was difficult, with little control over workflow and frequent urgent tasks, forcing us to micromanage and interrupt engineers. The team felt overwhelmed by a heavy workload, a bloated backlog, and too many “mandatory” tasks.
Externally, stakeholders were frustrated by slow delivery and a lack of visibility. Some C-level executives even questioned the team's value, as they struggled to understand what the team was working on and why. By then, the service had gained a reputation for being non-transparent, unresponsive and slow in supporting stakeholders.
One simple thing I did was visualizing our workflow - even for myself, it helped to understand how everything worked. Since then, we’ve proudly told everyone that we have 'Kanban.'
A year later, my manager encouraged and sponsored my Kanban certification, allowing me to fully realize its true potential. It became clear that a simple Kanban board with sticky notes was not Kanban yet.
The initial Kanban, as established in Toyota’s production system, differs from the Kanban methodology applied in IT. The core idea, developed between 2005 and 2008 at Microsoft and Corbis, focuses on introducing work-in-progress (WIP) limits and their proper implementation via the STATIK (Systems Thinking Approach to Introducing Kanban) framework.
How to Start Introducing Kanban
Excited with new knowledge, I returned to the office ready to implement Kanban, only to realize that the practical application of STATIK wasn’t fully covered in training and remained vague to me. The complexity of our internal processes was overwhelming, making it feel like a full-time job. Instead of applying STATIK fully from the start, I decided to focus on specific practices that addressed our pain points.
Step 0: Kanban Evangelism for the Team
It's great to be passionate about something, but it's even more important to have your team on board. After completing the training, I shared my knowledge with the team and involved them in suggesting changes. The most effective way to engage the team would be to play Kanban board games together, such as getKanban.
Step 1: Establishing a Manageable System
To create a manageable system, I defined service classes, WIP limits, and workload origins.
Service Classes
Just as airlines offer different service classes (business, economy), Kanban allows prioritization based on business value.
In our team, we categorized requests into:
- Expedite: Urgent tasks handled by the fastest available developer, released as soon as possible.
- Fixed Date: High-priority to be delivered by a specific date.
- Standard: All user requests and features adding value to products. These should follow a FIFO (First In, First Out) approach to reduce lead time.
- Bugs: Higher priority than internal improvements to ensure service quality.
- Intangible: Tasks with long-term impact that contribute to technical improvements.
Properly defined service classes help developers pick the right tasks without a manager’s intervention, eliminate effort spent on estimations, and balance business requests with technical improvements.
WIP Limits
Work-in-progress limits ensure a steady workflow, prevent overload, and help teams focus.
Our WIP limits were set as follows:
- Per Engineer: One task.
- Expedite Class: One active task at a time.
- Workflow Stages: Kick-off (2 tasks), Review (3 tasks) to prevent bottlenecks, Ready for Development (6 tasks) to protect (buffer) bottlenecks.
Understanding Workload Origins
Analyzing the frequency and nature of incoming requests helped us manage expectations and plan better.
- License-related requests: Up to seven per month, expected to be completed within two weeks.
- Feature requests: Around 13 per month, with 60% immediately - prioritized for completion within the next two months.
- Bugs: Around 20 per month.
Understanding workload dynamics allowed us to set realistic planning horizons and reserve buffers.
Step 2: Improving Stakeholder Satisfaction
The second goal was to enhance stakeholder satisfaction. It was achieved through cadence meetings, lead time optimization, and backlog triage.
Queue Replenishment Meeting
Kanban uses the term "cadence" for all regular meetings. Queue replenishment meetings serve the purpose of prioritization in Kanban, simply asking, "Which task should be done next?"
Initially, our team suffered from misaligned expectations. In project management, it's often suggested to identify the stakeholders. If that sounds too easy, let me tell you - it took me 1,5 years to fully understand the implicit rules of the game. For our team, the decision-makers on prioritization were a committee of 8 (!) managers.
Ironically, as a PM, I'm not a meeting person. They make me calculate coordination costs in my head. The first replenishment meeting wasn’t out of curiosity but a response to absence of synchronization. The situation escalated and it took six hours to sort out priorities.
After several iterations, we refined the process:
- Pre-triage meetings with department heads to eliminate irrelevant requests.
- A priority list containing a single top request from each stakeholder.
- Up to 30-minute decision-making meetings on demand. More and more often, the meetings would end in just 10 minutes or be completely postponed if I had the full context updated.
Lead Time Optimization
Stakeholders often want to know, “When will my request be done?” Like many teams, we tried to answer this with precise estimates and an up-to-date roadmap. Needless to say, it was tedious, time-consuming, and demotivating. Kanban experts advise not to estimate tasks at all, as it helps ease bottlenecks, often caused by developers who are repeatedly asked for their opinion. Although it is better suited for support teams due to their lower variability in tickets, the idea of skipping estimation also appealed to us.
Instead of juggling with ETAs, I dove into JIRA data to leverage the Lead Time metric (time to complete the entire process from feature request to release). In our case, over a 6-month timeline for closed tasks, Lead Time appeared as follows:
- 90% of expedited requests are completed within four weeks;
- 90% of standard requests are completed within 10 months;
- 90% of bugs are fixed within two days.
Another useful metric is Cycle Time, which measures how long a task takes once it is pulled by a developer to completion. Instead of estimating each task individually, historical data allows us to use Cycle Time Distribution for more reliable predictions.
By analyzing the Cycle Time Distribution Diagram, we can see how long the largest tasks have taken in the past. If a request seems vague or large, we can use the upper range of the distribution as a reference. If it feels more typical, we can refer to the most common cycle time to estimate how long it may take.
To reduce these metrics, we introduced many changes: optimized implementation for frequent licensing requests, invested in deployment process to release on demand, triaged tasks, pulled by FIFO, broke tasks down into small deliverable pieces, reduced transaction and coordination costs. Some were easy, like stop task assignments to developers and let them self-assign, while others required ongoing effort.
Backlog Triage
Together with the team lead, we spent an hour each week cleaning up our backlog. This ensured a balanced perspective between business priorities and technical impact. Over six months, we reduced the queue from 800 open requests to just 75 ready for development tasks - enough to sustain a steady work pace for 3-4 months if PM is somehow unavailable.
As a result, backlog management became significantly faster. Instead of sifting through hundreds of items, we could replenish the development buffer in minutes from the top of a triaged and prioritized backlog. This streamlined process prevented me, as a PM, from becoming a bottleneck when deciding what to pull next.
Conclusion
Introducing Kanban transformed our team into a more simple and manageable system, improving workflow visibility and efficiency.
- Median Lead Time for feature requests improved by 65% (from 12 weeks to 4 weeks for closed tasks).
- Backlog size refined by 91% (from over 800 tasks to 75 prepared to be pulled into development).
- For one of the licensing requests category optimization improved Lead Time by 86% (from a week to one day).
- Work in progress reduced at least doubly.
- Many services began releasing on demand or within five days instead of following three-week iterations.
- Coordination costs for work planning were significantly optimized.
- Stakeholders provided positive feedback. All of these changes were achieved through small, incremental improvements - driven as a side effort alongside my busy Product Manager role, with strong support from the team lead.
I hope my case study provides some inspiration. If you're considering Kanban for your team and are short on time, this 100-page book can be a quick and effective starting point. I also recommend Part I of Kanban in Action, which provides an interactive guide on how to visualize work with your team and set WIP limits. Start where you are, and may Kanban be with you!
Top comments (0)