Vact Kanban for Project Management: Visualize, Limit, and Improve
Kanban is a visual project management method that helps teams manage work by matching the amount of work in progress to the team’s capacity. Unlike Scrum, which operates in fixed-length sprints, Kanban uses a continuous flow model where work items move through stages as capacity becomes available. The method originated in Toyota’s manufacturing system in the 1940s and was adapted for knowledge work by David J. Anderson in the mid-2000s.
Kanban for Project Management: Visualize, Limit, and Improve
Core Principles of Kanban
Kanban is built on four foundational principles that distinguish it from other agile methodologies:
Start with what you do now. Kanban does not require reorganizing teams or changing job titles. It overlays onto existing workflows, making it one of the least disruptive frameworks to adopt.
Agree to pursue incremental change. Rather than revolutionary transformation, Kanban encourages small, continuous improvements. Teams evolve their processes over time based on data and observation.
Respect current roles and responsibilities. Kanban does not prescribe roles like Product Owner or Scrum Master. Existing team structures remain intact.
Encourage acts of leadership at all levels. Every team member is empowered to identify bottlenecks and suggest improvements, regardless of their position in the organization.
The Kanban Board
The kanban board is the primary tool for visualizing work. At its simplest, a board has three columns: To Do, In Progress, and Done. Most teams add columns that reflect their actual workflow stages. A software development team might use columns like Backlog, Ready, In Development, Code Review, Testing, and Done.
Each work item is represented by a card that moves across the board from left to right. Cards typically include a title, description, assignee, priority, and due date. Physical boards use sticky notes; digital tools like Trello, Jira, and ClickUp provide kanban board views with automation and reporting.
Swimlanes
Swimlanes are horizontal rows on the board that categorize work by type, priority, or team. For example, a board might have swimlanes for bugs, features, and technical debt. Swimlanes help teams visualize the distribution of work types and ensure that important categories are not neglected.
Work in Progress Limits
WIP limits are the defining practice of Kanban. Each column on the board has a maximum number of items allowed at any time. When a column reaches its WIP limit, no new work can enter until an existing item moves forward.
WIP limits prevent teams from starting too many things at once, which is the primary cause of slow delivery and context switching. Research by Gerald Weinberg showed that working on five simultaneous projects can waste up to 75% of productive time on context switching alone.
| Simultaneous Projects | Context Switching Loss | Productive Time |
|---|---|---|
| 1 | 0% | 100% |
| 2 | 10% | 80% |
| 3 | 20% | 60% |
| 4 | 30% | 40% |
| 5+ | 40-75% | 25-10% |
Setting appropriate WIP limits requires experimentation. Start with a limit equal to the number of team members working in that stage, then adjust based on flow metrics. If a column frequently reaches its limit and blocks upstream work, the team should investigate the bottleneck rather than simply raising the limit.
Kanban Metrics
Lead Time
Lead time measures the total time from when a work item is requested to when it is delivered. This is the metric customers care about because it represents how long they wait for their request to be fulfilled.
Cycle Time
Cycle time measures the time from when work begins on an item to when it is completed. Cycle time is typically shorter than lead time because it excludes time spent waiting in the backlog.
Throughput
Throughput is the number of work items completed per unit of time, typically per week. Tracking throughput over time helps teams forecast delivery dates and identify trends.
Cumulative Flow Diagram
The cumulative flow diagram (CFD) plots the number of items in each workflow stage over time. The vertical distance between lines represents the amount of work in each stage. A healthy CFD shows parallel, evenly spaced lines. Widening bands indicate bottlenecks where work is accumulating.
Kanban vs. Scrum
The most common question teams ask is whether to use Kanban or Scrum. The answer depends on the nature of the work:
Choose Kanban when:
- Work arrives unpredictably, such as support tickets or operational requests
- The team handles multiple work types with different priorities
- Stakeholders need continuous delivery rather than sprint-end releases
- The team resists time-boxed commitments
Choose Scrum when:
- The team builds products with clear sprint goals
- Regular planning and review cadences are valuable
- The team benefits from defined roles and ceremonies
- Stakeholders can wait for sprint boundaries to see progress
Many teams adopt a hybrid approach called Scrumban, combining Scrum’s sprint cadence with Kanban’s WIP limits and continuous flow principles.
Getting Started with Kanban
Map your current workflow stages into board columns. Do not design an ideal process; capture what actually happens today. Set initial WIP limits conservatively, observe where bottlenecks form, and adjust. Measure lead time and cycle time from day one so you have baseline data for improvement.
Hold regular review meetings, at least every two weeks, to discuss flow metrics and identify process improvements. Unlike Scrum, Kanban does not prescribe specific ceremonies, so teams should create their own cadence for effective team meetings that balance oversight with autonomy.