Kanban is a lean workflow management method that helps engineering teams visualise work, limit work in progress, and optimise the flow of value delivery. Unlike time-boxed approaches, Kanban provides a continuous flow model that is particularly effective for teams handling mixed workloads of features, bugs, and operational tasks. This guide shows engineering managers how to implement and optimise Kanban for their teams.
What Is Kanban and When to Use It
Kanban originated in Toyota's manufacturing system and was adapted for knowledge work by David J. Anderson. At its core, Kanban is built on four foundational principles: start with what you do now, agree to pursue incremental evolutionary change, respect the current process and roles, and encourage acts of leadership at all levels. These principles make Kanban uniquely non-prescriptive - it does not mandate specific roles, ceremonies, or cadences.
For engineering teams, Kanban excels in environments where work arrives unpredictably or where the team handles a mix of different work types. Support teams, platform teams, DevOps teams, and teams in maintenance mode often find Kanban more natural than sprint-based approaches. The continuous flow model means the team can start new work as soon as capacity becomes available, without waiting for the next sprint boundary.
The six core practices of Kanban are: visualise the workflow, limit work in progress, manage flow, make policies explicit, implement feedback loops, and improve collaboratively. Each practice builds on the others to create a system that reveals bottlenecks, reduces multitasking, and enables the team to deliver more predictably over time.
- Kanban does not prescribe roles, sprints, or specific ceremonies - it evolves your existing process
- Work in progress limits are the primary mechanism for improving flow and reducing cycle time
- Visualising the workflow makes bottlenecks and blockers visible to the entire team
- Kanban metrics focus on lead time, cycle time, and throughput rather than velocity
- The framework is particularly well-suited for teams with unpredictable or mixed workloads
Designing an Effective Kanban Board
Your Kanban board should reflect your team's actual workflow, not an idealised version of it. Start by mapping the stages work passes through from request to completion. For a typical engineering team, this might be: Backlog, Ready for Development, In Development, Code Review, QA, Ready for Deploy, and Done. Each column represents a distinct state in the workflow.
Add swim lanes to separate different types of work. Common swim lanes include features, bugs, and technical debt, or urgent versus standard priority. Swim lanes make it easy to see the balance of work types at a glance and can have their own WIP limits. Some teams add an expedite lane for urgent items that bypass normal flow, but this should be used sparingly.
Class of service policies define how different work types are handled. Expedite items get immediate attention, fixed-date items are scheduled backward from their deadline, standard items flow through the system in priority order, and intangible items (like technical debt) are pulled when capacity allows. Making these policies explicit prevents arguments about priorities and ensures fair treatment of all work types.
Setting WIP Limits and Managing Flow
Work in progress limits are the single most powerful lever in Kanban. By capping the number of items in each workflow state, WIP limits force the team to finish work before starting new work. This reduces context switching, shortens cycle times, and makes bottlenecks immediately visible. When a column hits its WIP limit, team members must help clear existing work rather than pulling new items.
Start with WIP limits that are slightly lower than your current work in progress. If your team of six typically has eight items in development simultaneously, set the initial WIP limit to six or seven. Observe what happens - if the team is constantly blocked, the limit may be too tight. If work flows smoothly, try reducing it further. The goal is to find the point where the team is fully utilised without being overloaded.
Monitor flow metrics regularly. Lead time measures the total time from request to delivery. Cycle time measures the time from when work starts to when it finishes. Throughput measures how many items the team completes per unit of time. Use cumulative flow diagrams to visualise how work moves through the system and identify stages where work accumulates. These metrics are more actionable than velocity because they directly measure what customers care about - how quickly their requests are fulfilled.
Kanban Cadences and Feedback Loops
While Kanban does not prescribe specific ceremonies, most successful Kanban teams establish regular cadences for replenishment, daily coordination, delivery review, and retrospection. The replenishment meeting - equivalent to backlog refinement - is where new work is prioritised and pulled into the system. The daily standup focuses on flow rather than individual status: which items are blocked, which columns are near their WIP limit, and where the team should focus attention.
Delivery reviews occur when work reaches the done column, providing an opportunity for stakeholder feedback. Unlike sprint reviews, these happen continuously as work is completed rather than at fixed intervals. This means stakeholders get value sooner and can provide feedback while the context is still fresh.
Service delivery reviews examine the team's metrics over time - are cycle times trending down, is throughput stable, are there recurring bottlenecks? These reviews, held fortnightly or monthly, inform systemic improvements. Retrospectives in Kanban focus on the flow system itself: where did work get stuck, what caused delays, and what process changes would improve flow?
Kanban vs Scrum: Making the Right Choice
The choice between Kanban and Scrum is not binary - many teams use a hybrid approach. Scrum excels when work is predictable, requirements are well-understood, and the team benefits from a regular delivery cadence. Kanban excels when work arrives unpredictably, the team handles diverse work types, or the overhead of sprint planning feels disproportionate to the value delivered.
Some teams start with Scrum and evolve toward Kanban as they mature. The discipline of sprints and ceremonies provides useful structure for teams new to agile, while Kanban's flexibility better serves experienced teams that have internalised agile principles. There is no shame in using different approaches for different contexts within the same organisation.
Scrumban - a blend of both frameworks - is increasingly popular. Teams use Scrum's sprint cadence for planning and retrospectives but apply Kanban's WIP limits and flow management within sprints. This hybrid captures the predictability benefits of sprints while reducing the overhead of strict sprint boundaries.
Key Takeaways
- WIP limits are the most powerful tool in Kanban - they reduce context switching and reveal bottlenecks
- Design your board to reflect your actual workflow, not an idealised process
- Focus on flow metrics like lead time, cycle time, and throughput rather than velocity
- Establish regular cadences for replenishment, daily coordination, and service delivery review
- Kanban and Scrum are not mutually exclusive - many teams benefit from a hybrid approach
Frequently Asked Questions
- How do you set initial WIP limits for an engineering team?
- A common starting point is to set WIP limits equal to the number of team members, or slightly below. For a team of six engineers, try a WIP limit of five or six for the development column. Observe the team for two to three weeks, then adjust. If the team is frequently idle because they cannot pull new work, increase the limit. If work is piling up and cycle times are long, decrease it. The right WIP limit creates a slight sense of urgency without causing stress.
- Can Kanban work without a dedicated Kanban board tool?
- Absolutely. Many teams start with a physical board using sticky notes on a whiteboard. Physical boards have the advantage of visibility - anyone walking past can see the state of work at a glance. However, for distributed teams, digital tools like Jira, Trello, or Linear are essential. The tool matters less than the practice of keeping the board updated and using it as the single source of truth for work status.
- How do you handle urgent items that need to bypass the normal flow?
- Create an expedite lane with its own WIP limit - typically one. Expedite items bypass the queue and receive immediate attention, but they disrupt normal flow, so use this sparingly. If more than ten to fifteen percent of your work is expedited, your prioritisation process needs attention. Track expedite usage as a metric and investigate the root causes of urgency rather than normalising it.
Get the Engineering Manager Field Guide
Our comprehensive field guide includes Kanban board templates, WIP limit calculators, and flow metric dashboards designed specifically for engineering managers.
Learn More