Waymaker

Kanban Methodology with Waymaker

Last Updated: October 10, 2025 Difficulty: Intermediate Estimated Reading Time: 16 minutes

Overview

Kanban is a powerful methodology for managing workflow through visualization, limiting work in progress, and continuously improving processes. Originally developed by Toyota for manufacturing, Kanban has become a cornerstone of modern knowledge work, enabling teams to deliver value continuously while maintaining sustainable pace and high quality.

Waymaker taskboards are naturally aligned with Kanban principles, providing visual boards, flexible workflows, and the controls needed to implement effective Kanban systems. This comprehensive guide shows you how to set up and operate a Kanban system in Waymaker, from basic board setup through advanced flow optimization and metrics.

What You'll Learn

  • Core Kanban principles and values
  • Visual management and board design
  • Pull system mechanics and implementation
  • Work in Progress (WIP) limits and their benefits
  • Flow optimization and bottleneck management
  • Cycle time and lead time measurement
  • Cumulative Flow Diagrams (CFD) analysis
  • Classes of Service for priority management
  • Continuous improvement and Kaizen
  • Kanban metrics and analytics
  • Scaling Kanban across teams
  • Common Kanban anti-patterns and solutions

Prerequisites

Kanban Principles and Values

Kanban is built on fundamental principles that guide how work flows through the system.

Core Kanban Principles

1. Visualize the Workflow

Make all work visible on a board so everyone can see:

  • What work exists
  • What state work is in
  • Where bottlenecks occur
  • How work flows through the system

2. Limit Work in Progress (WIP)

Constrain how much work can be in any stage:

  • Reduces multitasking
  • Improves focus
  • Exposes bottlenecks
  • Increases throughput

3. Manage Flow

Monitor and optimize how smoothly work moves:

  • Identify and remove blockers
  • Balance the system
  • Reduce cycle time
  • Maintain predictable delivery

4. Make Process Policies Explicit

Define and share how work should be done:

  • Clear acceptance criteria
  • Definition of done for each column
  • Who can move cards
  • When to pull new work

5. Implement Feedback Loops

Regular reviews to inspect and adapt:

  • Daily standups
  • Replenishment meetings
  • Service delivery reviews
  • Operations reviews

6. Improve Collaboratively, Evolve Experimentally

Use data and experiments to improve:

  • Measure current state
  • Propose improvements
  • Run experiments
  • Evaluate results

Kanban Values

Transparency: All work visible to all stakeholders

Balance: Balance demand against capacity

Collaboration: Work together to improve flow

Customer Focus: Optimize for value delivery

Flow: Continuous, smooth delivery of value

Leadership: Everyone can propose improvements

Understanding: Know your system before changing it

Agreement: Build consensus on changes

Respect: Respect current processes and roles

Why Choose Kanban?

Use Kanban When:

Continuous Flow Needed:

  • Support and maintenance work
  • Operations teams
  • Service delivery
  • Ongoing product development

Variable Work Items:

  • Different sizes and types of work
  • Unpredictable arrival of work
  • Mix of urgent and planned work

Team Maturity:

  • Team already working well
  • Incremental improvement desired
  • Minimal disruption required

Flexibility Required:

  • No fixed iterations
  • Work arrives continuously
  • Priorities change frequently

Process Visibility:

  • Need to see where work gets stuck
  • Want to identify bottlenecks
  • Require better forecasting

Kanban vs. Scrum:

AspectKanbanScrum
CadenceContinuous flowFixed sprints
ChangesAnytimeAfter sprint ends
RolesNo prescribed rolesProduct Owner, Scrum Master, Team
EstimationOptionalStory points required
WIP LimitsStrict limitsSprint capacity
Best ForContinuous deliveryIterative development
CeremoniesFew, flexiblePrescribed ceremonies

Setting Up Your Kanban Board

A well-designed board is the foundation of effective Kanban.

Kanban Board Structure

Basic Kanban Board:

Backlog → Ready → In Progress → Review → Done

Expanded Kanban Board:

Backlog → Ready → Dev → Code Review → QA → Deploy → Done

Software Development Board:

Backlog → Selected → Design → Development → Code Review → Testing → Deploy → Done

Step-by-Step Board Creation

Step 1: Create Your Kanban Board

  1. Navigate to Taskboards
  2. Click "Create Taskboard"
  3. Name: "[Team Name] Kanban Board" (e.g., "Support Team Kanban")
  4. Type: Project
  5. Description: Board purpose and policies
  6. Create board

Step 2: Design Your Workflow Columns

Map your actual workflow process:

Identify Work States:

  • What stages does work go through?
  • Where does work wait?
  • What approvals are needed?
  • What hand-offs occur?

Create Columns for Each State:

Example: Support Team

  • Backlog: New tickets
  • Prioritized: Triaged and ready to work
  • In Progress: Being worked on
  • Awaiting Customer: Need customer response
  • Resolved: Fixed, awaiting verification
  • Done: Verified and closed

Example: Development Team

  • Backlog: Feature requests and bugs
  • Ready: Refined and ready to develop
  • Development: Coding in progress
  • Code Review: Awaiting peer review
  • QA Testing: In testing
  • Ready to Deploy: Tested, awaiting deployment
  • Done: Deployed to production

To Configure:

  1. Board Settings → Sections
  2. Add columns for each workflow state
  3. Order columns left-to-right (start → finish)
  4. Set "Done" as completion status
  5. Save

Step 3: Define Column Definitions

For each column, document:

Purpose: What this column represents

Entry Criteria: When work can enter this column

Exit Criteria: When work can leave this column

WIP Limit: Maximum work items allowed

Who: Who performs work in this column

Example:

## Column: Code Review

### Purpose
Code is complete and needs peer review before proceeding to testing.

### Entry Criteria
- Code complete and committed
- Unit tests written and passing
- Self-review completed
- No known bugs

### Exit Criteria
- At least 1 peer review approved
- All review comments addressed
- Code merged to main branch

### WIP Limit
3 items maximum

### Who
Any senior developer can review

Add to Board Description: Document all column definitions in board description for team reference.

Step 4: Set Up Work Item Types (Optional)

Categorize different types of work:

Common Work Types:

  • Feature: New functionality
  • Bug: Defect to fix
  • Support: Customer support ticket
  • Maintenance: Technical debt or refactoring
  • Urgent: Critical, expedited work

In Waymaker:

  • Use tags to indicate work type
  • Or use task priority field
  • Filter board by work type as needed

Step 5: Establish Initial WIP Limits

Set WIP limits for each column:

Starting Point:

  • 1.5 × number of people working in that column
  • Example: 3 developers → WIP limit of 4-5 items

Adjust Based On:

  • Team feedback
  • Bottleneck observations
  • Flow metrics

Communicate WIP Limits:

  • Add to column name: "In Progress (WIP: 3)"
  • Document in board description
  • Or add visual indicator (future feature)

Your Kanban board is ready!

Understanding Pull Systems

Kanban uses a "pull" system where work is pulled only when capacity exists.

Pull vs. Push

Push System (Traditional):

  • Work assigned to people
  • Work pushed downstream whether ready or not
  • Inventory builds up
  • Bottlenecks hidden
  • Quality suffers under pressure

Pull System (Kanban):

  • People pull work when ready
  • Downstream pulls from upstream
  • Inventory limited by WIP
  • Bottlenecks visible immediately
  • Quality maintained through controlled flow

How Pull Works

Trigger: Downstream capacity available

Signal: Upstream work pulled

Example:

[Ready: 5 items] → [Dev: 2/3 items] → [Review: 3/3 items]
                        ↑
                    Pull signal
                 (capacity available)

Developer finishes item, moves to Review.
Review is now at WIP limit (3/3).
Developer has capacity, pulls from Ready.

Benefits:

  • Work started only when capacity exists
  • Reduced multitasking
  • Better focus
  • Improved quality
  • Predictable flow

Implementing Pull in Waymaker

Daily Workflow:

  1. Check Your Capacity

    • How many items am I working on?
    • Am I at my WIP limit?

  2. Finish Before Starting

    • Complete current work
    • Move to next column
    • Now have capacity

  3. Pull New Work

    • Look at previous column (upstream)
    • Pull highest priority item
    • Move to your column
    • Start work

Team Coordination:

  • Daily standup: "What's blocking your work?"
  • Team helps resolve blockers
  • Focus on flow, not individual productivity

Pull Policies:

Who Can Pull:

  • Person with capacity in column
  • Self-organized team members

When to Pull:

  • When WIP limit allows
  • When higher priority work arrives (expedite)
  • When blocked work clears

What to Pull:

  • Highest priority item first
  • Blocked items only when unblocked
  • Work that fits capacity (size consideration)

Work in Progress (WIP) Limits

WIP limits are the heart of Kanban, controlling flow and exposing constraints.

Why Limit WIP?

Benefits of WIP Limits:

Improved Focus:

  • Fewer context switches
  • Deep work on fewer items
  • Higher quality output

Faster Delivery:

  • Complete work faster
  • Reduced cycle time
  • More predictable flow

Expose Bottlenecks:

  • Constraints become visible
  • Team addresses root causes
  • System improves

Reduce Multitasking:

  • Work on one thing at a time
  • Finish before starting new
  • "Stop starting, start finishing"

Better Collaboration:

  • Team swarms on blockers
  • Help downstream when upstream blocked
  • Collective ownership

Setting WIP Limits

Per Column Limits:

Formula: WIP Limit = (Number of People) × (1.5 to 2)

Example:

  • 3 developers in "Development" column
  • WIP Limit: 3 × 1.5 = 4-5 items

Considerations:

  • Work item size variation
  • Complexity of work
  • Dependencies
  • Team experience

Per Person Limits:

Recommendation: 1-2 items per person maximum

Benefits:

  • Forces focus
  • Prevents multitasking
  • Clear ownership

Global Board Limit:

Total work items on the entire board:

Formula: (Number of Columns) × (Average WIP per Column)

Example:

  • 5 active columns
  • Average WIP of 3 per column
  • Global limit: 15 items

Respecting WIP Limits

When WIP Limit Reached:

DO:

  • ✅ Help complete work in that column
  • ✅ Help remove blockers
  • ✅ Swarm on blocked items
  • ✅ Help downstream columns
  • ✅ Improve processes
  • ✅ Wait for capacity (pull rule)

DON'T:

  • ❌ Violate WIP limit
  • ❌ Start new work
  • ❌ Push work forward
  • ❌ Ignore the constraint
  • ❌ Work on backlog items

Temporary WIP Limit Violations:

When Allowed:

  • Critical production issue (expedite)
  • Customer escalation
  • Blocked work unexpectedly unblocked

Requirements:

  • Team agreement
  • Temporary only
  • Document reason
  • Return to limit ASAP

Adjusting WIP Limits

Increase WIP Limit When:

  • Column consistently empty
  • Team has excess capacity
  • Work items very small

Decrease WIP Limit When:

  • Too much multitasking
  • Long cycle times
  • Quality issues
  • Team feels overwhelmed

Experiment with Limits:

  1. Set initial limit
  2. Run for 2 weeks
  3. Review metrics (cycle time, throughput)
  4. Adjust limit
  5. Repeat

In Waymaker:

  • Document current WIP limits in board description
  • Update column names with limits: "Dev (WIP: 3)"
  • Review WIP limits monthly
  • Use comments to track limit changes and rationale

Managing Flow

Flow is how smoothly work moves through the system from start to finish.

Measuring Flow

Key Metrics:

Throughput:

  • Number of items completed per time period
  • Example: 15 items per week
  • Higher throughput = more delivery

Cycle Time:

  • Time from work started to work completed
  • Example: 3 days average
  • Lower cycle time = faster delivery

Lead Time:

  • Time from work requested to work completed
  • Example: 7 days average
  • Lower lead time = better responsiveness

Work in Progress:

  • Total items in the system
  • Example: 12 items currently active
  • Lower WIP = faster flow (generally)

Flow Efficiency:

  • Percentage of time work is actively progressing (not waiting)
  • Example: 40% (work progresses 40% of the time, waits 60%)
  • Higher efficiency = less waste

Little's Law

Formula: Cycle Time = WIP / Throughput

Example:

  • WIP: 10 items
  • Throughput: 5 items/week
  • Cycle Time: 10 / 5 = 2 weeks

Implications:

  • Reduce WIP → Faster cycle time
  • Increase throughput → Faster cycle time
  • Predictable relationship

Identifying Bottlenecks

Signs of Bottleneck:

  • Column consistently at WIP limit
  • Work accumulates before column
  • Column takes longest time
  • Team members often waiting for that column

Visual Indicators:

[Ready: 3 items] → [Dev: 2 items] → [Review: 8 items ⚠️] → [Done]
                                         ↑
                                    Bottleneck

Addressing Bottlenecks:

1. Add Capacity

  • More people in bottleneck column
  • Cross-train team members
  • Temporary reassignment

2. Reduce Demand

  • Limit WIP in upstream columns
  • Reduce input rate
  • Filter low-value work

3. Improve Efficiency

  • Automate repetitive tasks
  • Remove waste
  • Better tools
  • Process improvements

4. Change Process

  • Split column into smaller steps
  • Parallel processing
  • Eliminate unnecessary steps

In Waymaker:

  • Regularly review board for accumulation
  • Use list view to see item counts per column
  • Tag bottleneck items for visibility
  • Discuss bottlenecks in team meetings

Optimizing Flow

Flow Optimization Strategies:

1. Reduce Batch Size

  • Smaller work items flow faster
  • Break large items into smaller
  • Release frequently

2. Minimize Handoffs

  • Cross-functional teams
  • Reduce dependencies
  • End-to-end ownership

3. Eliminate Waste

  • Remove unnecessary approvals
  • Reduce rework
  • Automate manual tasks
  • Simplify processes

4. Balance the System

  • Adjust WIP limits
  • Reallocate resources
  • Address constraints
  • Smooth demand

5. Improve Predictability

  • Standardize work items
  • Document processes
  • Reduce variability
  • Build expertise

Kanban Metrics and Analytics

Data-driven insights enable continuous improvement.

Cycle Time

Definition: Time from when work starts to when it's done

Calculation:

Cycle Time = Done Date - Started Date

Example:
Task started: Oct 1
Task completed: Oct 5
Cycle Time: 4 days

Uses:

  • Predict delivery dates
  • Identify slow-moving work
  • Measure improvement over time

Target:

  • Lower cycle time = faster delivery
  • Consistent cycle time = predictability

In Waymaker:

  • Track start date (when moved to first active column)
  • Track completion date (when moved to Done)
  • Calculate manually or use reporting (future feature)

Lead Time

Definition: Time from when work is requested to when it's done

Calculation:

Lead Time = Done Date - Request Date

Example:
Task created: Sep 25
Task completed: Oct 5
Lead Time: 10 days

Uses:

  • Customer perspective of delivery time
  • Set expectations for stakeholders
  • Measure total system efficiency

Difference from Cycle Time:

  • Lead Time includes waiting in backlog
  • Cycle Time is only active work time

Throughput

Definition: Number of work items completed in a time period

Calculation:

Throughput = Count of Completed Items / Time Period

Example:
Week 1: 12 items completed
Week 2: 15 items completed
Week 3: 13 items completed
Average Throughput: 13.3 items/week

Uses:

  • Forecast future capacity
  • Plan commitments
  • Measure team productivity

Increasing Throughput:

  • Reduce bottlenecks
  • Improve efficiency
  • Remove blockers
  • Optimize processes

In Waymaker:

  • Filter to Done section
  • Count items completed per week
  • Track trend over time

Cumulative Flow Diagram (CFD)

What It Shows:

  • Work items in each stage over time
  • WIP trends
  • Bottleneck identification
  • Flow stability

How to Read CFD:

X-Axis: Time (days/weeks)

Y-Axis: Count of work items

Bands: Each column/stage

Vertical Distance: WIP in that stage

Horizontal Distance: Cycle time

Healthy CFD:

  • Smooth, parallel bands
  • Consistent distance between bands
  • Steady upward trend

Unhealthy CFD:

  • Bulging bands (bottleneck)
  • Widening bands (increasing cycle time)
  • Flat bands (no throughput)

Example Analysis:

If "Code Review" band is bulging:
→ Bottleneck in code review
→ Need more reviewers or faster reviews
→ Reduce WIP in Development (upstream)

In Waymaker:

  • Cumulative Flow Diagram (future feature)
  • Manual tracking in spreadsheet currently

Service Level Expectation (SLE)

Definition: Forecast for how long work takes

Format: "X% of work items are completed within Y days"

Example:

  • 85% of items completed within 5 days
  • 95% of items completed within 8 days

Creating SLE:

  1. Collect cycle time data (30+ items)
  2. Calculate percentiles
  3. Set expectation (e.g., 85th percentile)
  4. Communicate to stakeholders

Uses:

  • Set customer expectations
  • Identify outliers
  • Measure consistency
  • Improve forecasting

In Waymaker:

  • Track cycle time for each completed item
  • Calculate percentiles in spreadsheet
  • Document SLE in board description

Aging Work Items

Definition: How long has an item been in progress?

Why Track:

  • Identify blocked items
  • Prevent work from getting stuck
  • Proactive intervention

Aging Thresholds:

  • Green: 0-3 days (normal)
  • Yellow: 4-7 days (watch)
  • Red: 8+ days (intervention needed)

Actions for Aging Items:

  • Review with team
  • Identify blockers
  • Swarm if needed
  • Escalate if stuck
  • Consider breaking down

In Waymaker:

  • Sort by start date
  • Identify oldest items
  • Add comments for aging items
  • Tag with "blocked" if stuck

Classes of Service

Different types of work require different treatment.

Work Classification

Standard Class:

  • Regular work items
  • Normal priority
  • Flow through standard process
  • Most work falls here

Fixed Delivery Date:

  • Deadline-driven work
  • Time-sensitive
  • Higher priority
  • Examples: regulatory compliance, client commitments

Expedite:

  • Critical, urgent work
  • Top priority
  • Bypass WIP limits (temporarily)
  • Examples: production outages, security issues

Intangible:

  • Non-customer-facing work
  • Technical debt
  • Process improvements
  • Innovation time

Visualizing Classes

Option 1: Swimlanes

Horizontal lanes for each class:

┌─────────────────────────────────────┐
│ Expedite     │    │    │    │       │
├─────────────────────────────────────┤
│ Fixed Date   │    │    │    │       │
├─────────────────────────────────────┤
│ Standard     │    │    │    │       │
├─────────────────────────────────────┤
│ Intangible   │    │    │    │       │
└─────────────────────────────────────┘
  Backlog   Ready  Dev  Review  Done

Option 2: Color Coding

Different colors for each class:

  • Red: Expedite
  • Orange: Fixed Date
  • Blue: Standard
  • Gray: Intangible

Option 3: Tags

Use tags in Waymaker:

  • "expedite"
  • "fixed-date"
  • "standard"
  • "intangible"

Class of Service Policies

Expedite:

  • Limit: 1 expedite item at a time maximum
  • Policy: Can bypass WIP limits
  • Pull: Immediately, interrupting current work
  • Review: Why did this become expedite? How to prevent?

Fixed Date:

  • Limit: No more than 20% of WIP
  • Policy: Higher priority than Standard
  • Pull: Based on deadline (backward scheduling)
  • Review: Are deadlines realistic? Can we commit fewer?

Standard:

  • Limit: Majority of work
  • Policy: Pull in priority order
  • Pull: When capacity available
  • Review: Is prioritization effective?

Intangible:

  • Limit: 10-20% of capacity
  • Policy: Regular investment in improvement
  • Pull: When no higher priority work
  • Review: Is investment sufficient?

In Waymaker:

  • Document policies in board description
  • Use tags or colors to identify class
  • Filter by class of service
  • Track percentage of each class

Kanban Cadences (Meetings)

Regular meetings provide structure for flow management and improvement.

Daily Standup

Purpose: Coordinate work and identify blockers

Duration: 15 minutes maximum

Frequency: Daily, same time

Focus: The board, not the people

Flow:

  1. Walk the board right-to-left (Done → Backlog)
  2. For each item: "Is this moving? Any blockers?"
  3. Identify who can help with blockers
  4. Discuss after meeting if deep dive needed

Questions:

  • "What's blocking this item?"
  • "Who can help unblock it?"
  • "Are we respecting WIP limits?"
  • "Any urgent work coming?"

Not:

  • Detailed status reports
  • Problem-solving (take offline)
  • Individual updates

In Waymaker:

  • Display board during standup
  • Filter to active columns
  • Update card status live
  • Add comments for blockers

Replenishment Meeting

Purpose: Pull new work into the system

Duration: 30-60 minutes

Frequency: Weekly or bi-weekly

Attendees: Team + stakeholders

Activities:

  1. Review capacity (available WIP)
  2. Review backlog items
  3. Select items to pull into Ready column
  4. Prioritize new work
  5. Ensure work is ready (Definition of Ready)

Definition of Ready:

  • Clear description
  • Acceptance criteria defined
  • Dependencies identified
  • Estimated (if using estimates)
  • Value understood

In Waymaker:

  • Filter to Backlog
  • Sort by priority
  • Move selected items to Ready
  • Set priority field
  • Add refinement details to description

Service Delivery Review

Purpose: Review flow metrics and quality

Duration: 60 minutes

Frequency: Monthly

Attendees: Team + management

Agenda:

  1. Review Metrics

    • Throughput trends
    • Cycle time trends
    • WIP levels
    • Service level expectation (SLE) performance

  2. Analyze Issues

    • Bottlenecks identified
    • Quality problems
    • Customer escalations
    • Blocked items

  3. Identify Improvements

    • Process changes needed
    • Capacity adjustments
    • Tool improvements

  4. Action Items

    • Assign improvement actions
    • Set deadlines
    • Review past actions

In Waymaker:

  • Prepare metrics report
  • Review completed and in-progress work
  • Document action items as tasks
  • Track improvement initiatives

Operations Review

Purpose: Strategic improvement and process evolution

Duration: 60-90 minutes

Frequency: Quarterly

Attendees: Team + leadership + stakeholders

Agenda:

  1. Review System Performance

    • Long-term metric trends
    • SLE achievement
    • Customer satisfaction
    • Team satisfaction

  2. Evaluate Service Fitness

    • Are we delivering the right things?
    • Is our process effective?
    • Do we have the right capacity?

  3. Strategic Improvements

    • Process redesign ideas
    • Technology investments
    • Team structure changes
    • Skill development needs

  4. Experiments

    • Propose process experiments
    • Review past experiments
    • Plan next experiments

In Waymaker:

  • Compile quarterly report
  • Document experiments and results
  • Create tasks for strategic initiatives

Continuous Improvement

Kaizen—continuous improvement—is core to Kanban.

Improvement Culture

Everyone Can Improve:

  • Any team member can suggest improvement
  • Ideas welcomed and evaluated
  • Experiments encouraged
  • Learn from failures

Data-Driven Decisions:

  • Measure current state
  • Propose change hypothesis
  • Run experiment
  • Measure results
  • Keep change if improved, revert if not

Small Changes:

  • Incremental improvements
  • Low risk
  • Easy to revert
  • Compound over time

Improvement Process

Step 1: Identify Opportunity

Sources:

  • Metrics showing problems
  • Team member observations
  • Customer feedback
  • Retrospective discussions
  • Bottleneck analysis

Step 2: Analyze Root Cause

Techniques:

  • 5 Whys
  • Fishbone diagram
  • Pareto analysis
  • Process mapping

Example - 5 Whys:

Problem: Items stuck in Code Review too long

Why? Not enough reviewers
Why? Only senior devs can review
Why? Juniors lack confidence
Why? No training on code review process
Why? No formal process documented

Root Cause: Need documented code review process and training

Step 3: Propose Improvement

Improvement Hypothesis: "If we [change], then [metric] will [improve] because [reasoning]"

Example: "If we create a code review checklist and train junior developers, then average code review time will decrease from 2 days to 1 day because more team members can review code."

Step 4: Run Experiment

  • Define success criteria
  • Set experiment duration (2-4 weeks)
  • Implement change
  • Measure results
  • Document learnings

Step 5: Evaluate and Decide

If Improved:

  • Keep the change
  • Document new process
  • Share learnings
  • Look for next improvement

If Not Improved:

  • Revert to previous process
  • Analyze why it didn't work
  • Refine hypothesis
  • Try different approach

In Waymaker:

  • Create "Improvements" layer for tracking
  • Document each improvement as task
  • Include hypothesis, experiment details, results
  • Close when complete (success or failure)

Kaizen Events

Focused improvement sessions:

Purpose: Rapid improvement on specific issue

Duration: 2-4 hours

Process:

  1. Define problem (1 hour)
  2. Analyze root causes (30 min)
  3. Brainstorm solutions (30 min)
  4. Select solution (30 min)
  5. Plan implementation (30 min)

Output: Action plan for improvement

In Waymaker:

  • Schedule Kaizen event
  • Document problem in task description
  • Capture brainstorm ideas in comments
  • Create implementation tasks
  • Track results

Scaling Kanban

As teams grow, Kanban can scale effectively.

Team-Level Kanban

Single Team Board:

  • 5-10 team members
  • One workflow
  • Shared WIP limits
  • Daily coordination

Works Well For:

  • Single product team
  • Support team
  • Operations team

Portfolio Kanban

Multiple Teams, One Product:

Structure:

Portfolio Board (Features/Epics)
    ↓
Team A Board (Stories/Tasks)
Team B Board (Stories/Tasks)
Team C Board (Stories/Tasks)

Portfolio Board:

  • High-level work items (features, epics)
  • Strategic prioritization
  • Cross-team dependencies
  • Quarterly planning

Team Boards:

  • Detailed work items
  • Daily execution
  • Team-specific WIP limits
  • Weekly replenishment

In Waymaker:

  • Create separate board for portfolio
  • Create separate boards per team
  • Link related work items (dependencies)
  • Use tags for cross-board tracking

Service-Oriented Kanban

Multiple Work Types:

Different Boards for Different Services:

  • Development Kanban
  • Support Kanban
  • Operations Kanban

Shared Resources:

  • Team members work on multiple boards
  • Personal WIP limits across boards
  • Coordinate capacity allocation

Example:

Developer personal WIP limit: 2 items total

Current state:
- 1 item from Development Kanban
- 1 item from Support Kanban
- Cannot pull more until one completes

Cross-Team Coordination

Coordination Mechanisms:

Scrum of Kanbans:

  • Daily cross-team standup
  • Representatives from each team
  • Discuss dependencies and blockers

Shared Backlog:

  • Single prioritized backlog
  • Teams pull from shared backlog
  • Coordinated replenishment

Team of Teams:

  • Periodic sync meeting
  • Align on strategic priorities
  • Resolve cross-team issues

In Waymaker:

  • Use dependencies for cross-team work
  • Tag items with team name
  • Filter by team to see specific work

Common Kanban Anti-Patterns

Avoid these pitfalls that undermine Kanban effectiveness.

Anti-Pattern: No WIP Limits

Problem:

  • Team has no WIP limits
  • All work is "in progress"
  • Multitasking rampant
  • Nothing finishes

Solution:

  • ✅ Set WIP limits on every column
  • ✅ Start conservative (lower limits)
  • ✅ Enforce limits strictly
  • ✅ Review and adjust over time

Anti-Pattern: Ignoring WIP Limits

Problem:

  • WIP limits defined but not followed
  • "Just this once" becomes habit
  • Limits become meaningless

Solution:

  • ✅ Team commits to respecting limits
  • ✅ Visualize limits clearly
  • ✅ Discuss violations immediately
  • ✅ Address root cause of violations

Anti-Pattern: Too Many Columns

Problem:

  • 15+ columns on board
  • Micro-managing workflow
  • Complexity overwhelms clarity

Solution:

  • ✅ Combine related columns
  • ✅ 5-8 columns maximum
  • ✅ Focus on major state changes
  • ✅ Keep it simple

Anti-Pattern: No Definition of Done

Problem:

  • Unclear when work is complete
  • Work moves prematurely
  • Rework required

Solution:

  • ✅ Define entry/exit criteria for each column
  • ✅ Document in board description
  • ✅ Enforce criteria before moving cards
  • ✅ Review criteria regularly

Anti-Pattern: No Metrics

Problem:

  • No data on flow
  • Decisions based on feelings
  • No way to measure improvement

Solution:

  • ✅ Track cycle time
  • ✅ Measure throughput
  • ✅ Monitor WIP
  • ✅ Review metrics regularly

Anti-Pattern: Stale Backlog

Problem:

  • Hundreds of items in backlog
  • Old, irrelevant work
  • Can't find priority items

Solution:

  • ✅ Limit backlog size (50-100 items max)
  • ✅ Purge old items quarterly
  • ✅ Keep only ready/soon-to-be-ready work
  • ✅ Archive low-priority items

Anti-Pattern: Individual Assignments

Problem:

  • All work assigned to individuals
  • No swarming or helping
  • Bottlenecks ignored

Solution:

  • ✅ Team ownership of work
  • ✅ Self-assignment when pulling
  • ✅ Swarm on blocked items
  • ✅ Help where needed most

Tips & Best Practices

Getting Started:

  • Start with your current process (don't redesign everything)
  • Visualize existing workflow first
  • Add WIP limits incrementally
  • Experiment and adjust
  • Focus on flow, not perfect process

WIP Management:

  • Set limits lower than comfortable
  • Respect limits strictly
  • Use limits to expose bottlenecks
  • Adjust based on data, not pressure
  • Lower WIP generally = faster flow

Flow Optimization:

  • Measure cycle time consistently
  • Identify and address bottlenecks
  • Minimize work item size
  • Reduce handoffs
  • Automate repetitive tasks

Team Practices:

  • Walk the board right-to-left in standups
  • Swarm on blocked items
  • Finish work before starting new
  • Help downstream before pulling new work
  • Celebrate flow improvements

Metrics and Improvement:

  • Track throughput and cycle time
  • Review metrics monthly
  • Run small experiments
  • Learn from data
  • Share learnings with team

Scaling:

  • Keep team boards simple
  • Coordinate across teams with shared backlogs
  • Use dependencies for cross-team work
  • Maintain team autonomy
  • Share best practices across teams

Related Articles

Need More Help?

If you have questions about implementing Kanban, setting WIP limits, or optimizing flow with Waymaker, please contact support or visit our community forums. Our team can help you design an effective Kanban system for your team.