Chapter 12 of 20
Kanban, Flow-Based Work, and Extreme Programming (XP) Basics
Discover how Kanban visualizes work and manages flow, and how Extreme Programming (XP) uses disciplined engineering practices to boost quality and responsiveness.
From Sprints to Flow: Where Kanban and XP Fit
Why Kanban and XP Matter
You know Scrum from earlier modules. This module adds Kanban (flow-based work) and Extreme Programming (XP), which focus on how work moves and how code is built.
Three Agile Styles
- Scrum: sprints, roles, and events.
- Kanban: continuous flow, visual boards, WIP limits.
- XP: technical practices like TDD, pair programming, CI, and refactoring.
How They Combine
Teams often mix: Scrum for structure, Kanban for flow visualization and WIP limits, and XP for high-quality engineering and fast, safe change.
What CAPM Tests Here
Expect questions that compare Scrum vs Kanban vs XP, ask when to use flow-based work, and which XP practice solves a given quality or flow problem.
Kanban Fundamentals: Visualizing Work and Managing Flow
What Is Kanban?
Kanban is a method to visualize work, limit work-in-progress, and manage flow. It makes invisible knowledge work visible and easier to improve.
Core Kanban Practices
- Visualize work on a board
- Limit WIP
- Manage flow
- Make policies explicit
- Use feedback loops to improve
A Simple Kanban Board
Example columns: To Do, In Progress, Code Review, Testing, Done. Each card is a work item that moves left to right as it progresses.
When Kanban Fits
Kanban suits teams with unpredictable incoming work, such as support or operations, or teams improving an existing process without adopting full Scrum.
Designing a Kanban Board and Setting WIP Limits
Mapping Workflow
Start by listing key stages from idea to Done: for example Backlog, Ready, In Progress, Code Review, Test, Done. These become columns.
What Is a WIP Limit?
A WIP limit is the maximum number of items allowed in a column at once. Example: In Progress (3), Code Review (2), Test (2).
Why Limit WIP?
Low WIP cuts multitasking, exposes bottlenecks, and encourages collaboration to finish work instead of starting more items.
Pull, Not Push
In Kanban, you pull a new item into a column only when there is capacity under the WIP limit. This protects flow and reduces overload.
Flow Metrics: Cycle Time, Lead Time, and Throughput
Lead Time
Lead time is from when a request is made until it is completed. It reflects how long a stakeholder waits from asking to getting the result.
Cycle Time
Cycle time is from when the team starts work on an item until it is completed. It reflects how long the team actively works on it.
Throughput
Throughput is how many work items are finished per unit of time, such as 10 items per week. It is a flow productivity measure.
Why These Metrics Matter
Short, predictable cycle times and stable throughput show healthy flow. WIP limits help achieve this, enabling better forecasting and adaptation.
Worked Example: Using WIP Limits and Flow Metrics to Improve
The Overloaded Team
A 5-person team has many items in progress, lots of multitasking, and simple fixes taking over a week. Average cycle time is 8 days.
Adding WIP Limits
They set WIP limits: In Progress (3), Test (2). When a column is full, no new work starts. People help finish existing items instead.
Results After a Month
Cycle time drops from 8 to 4 days. Throughput rises from 10 to 14 items per week. Flow is smoother and less stressful.
Exam Pattern
In scenario questions, prefer answers that limit WIP and focus on finishing work to improve flow, not starting more items at once.
Extreme Programming (XP): Purpose and Core Values
What Is XP?
Extreme Programming (XP) is an agile approach focused on technical excellence, high quality, and frequent delivery in software development.
Goals of XP
XP aims to deliver high-quality software, respond quickly to change, and keep the cost of change low through clean, well-tested code.
XP Values
Common XP values: Communication, Simplicity, Feedback, Courage, and Respect. These guide its engineering practices.
XP with Scrum or Kanban
Scrum/Kanban manage planning and flow; XP defines how developers write, test, integrate, and improve code to support frequent change.
Key XP Practices: Pair Programming, TDD, CI, and Refactoring
Pair Programming
Two developers work at one workstation on the same code, swapping roles. It improves quality, spreads knowledge, and embeds code review.
Test-Driven Development (TDD)
TDD writes tests before code. Cycle: Red (failing test), Green (minimal code to pass), Refactor (clean up with tests still passing).
Continuous Integration (CI)
CI means integrating code into a shared repo frequently, with automated builds and tests on each change to catch issues early.
Refactoring
Refactoring improves internal code structure without changing behavior, supported by tests and CI so teams can change code safely.
XP in Action: Fixing Late Integration and Quality Problems
The Problem
A Scrum team integrates code only at sprint end. Reviews reveal broken features and regressions. Integration is painful and risky.
Adopting CI and TDD
They start continuous integration with automated builds and tests. Developers write tests first (TDD), building a strong regression suite.
Refactoring and Pairing
With tests in place, they refactor regularly and pair program on complex code. Code becomes cleaner and easier to change.
Outcomes and Exam Angle
Defects drop, integration issues surface quickly, and change feels safer. On the exam, favor CI, TDD, and refactoring over hardening sprints.
Scrum vs Kanban vs XP: Planning, Roles, and WIP
Scrum Snapshot
Scrum uses timeboxed sprints, defined roles (Product Owner, Scrum Master, Developers), and events. WIP is limited by sprint capacity.
Kanban Snapshot
Kanban uses continuous flow, no required roles, and explicit WIP limits per column. Work is pulled when capacity is available.
XP Snapshot
XP centers on engineering practices like TDD, CI, refactoring, and pair programming, not on roles or flow visualization.
Key Distinction
Scrum/Kanban manage how work is planned and flows. XP manages how software is built technically. Do not treat XP as a full PM framework.
Quick Check: Kanban and Flow Concepts
Test your understanding of Kanban basics and flow metrics.
A team using a Kanban board finds that many items sit in 'In Progress' for a long time and average cycle time is increasing. Which action best reflects Kanban principles to improve flow?
- Increase the WIP limit for 'In Progress' so more work can be started and developers stay fully utilized
- Introduce or tighten a WIP limit for 'In Progress' and encourage the team to focus on finishing existing items
- Add more detailed columns to the board so each micro-step is tracked separately
- Ask each developer to manage their own private list of tasks instead of using a shared board
Show Answer
Answer: B) Introduce or tighten a WIP limit for 'In Progress' and encourage the team to focus on finishing existing items
Kanban aims to improve flow by limiting WIP and encouraging finishing work before starting more. Tightening the WIP limit for 'In Progress' exposes bottlenecks and reduces multitasking, which tends to reduce cycle time. Increasing WIP or hiding work in private lists harms transparency and flow. Adding many micro-steps can add complexity without addressing the underlying overload.
Quick Check: XP Practices and Benefits
Test your understanding of key XP practices.
A Scrum team frequently discovers integration problems and regressions at the end of each sprint. Which combination of practices is MOST aligned with Extreme Programming (XP) to address this issue?
- Lengthen sprints and add a separate hardening sprint for integration and testing
- Adopt continuous integration with automated tests and regular refactoring
- Limit WIP on the Kanban board and stop accepting new items mid-sprint
- Assign a dedicated tester role to manually test all features before the Sprint Review
Show Answer
Answer: B) Adopt continuous integration with automated tests and regular refactoring
XP emphasizes technical practices like continuous integration, automated testing (often via TDD), and refactoring to catch integration problems early and keep code clean. Lengthening sprints or adding hardening sprints delays feedback. Limiting WIP is a Kanban practice that helps flow but does not directly solve late integration. A dedicated tester may help, but without CI and refactoring the underlying technical risk remains.
Thought Exercise: Choosing Scrum, Kanban, XP, or a Hybrid
Work through this scenario and decide which approach (or combination) fits best.
Scenario
You are managing a project for an internal IT department. There are two main streams of work:
- New feature development for a web application (planned releases every 2–3 weeks).
- Unplanned support requests and bug fixes that arrive randomly from users.
The team currently struggles with:
- Long lead times for support tickets.
- Integration problems at the end of each release.
- Multitasking across features and support.
Your task
- On a scratchpad, sketch how you might structure the work:
- Would you use Scrum for certain work and Kanban for others?
- Where would XP practices fit?
- Reflect on these guiding questions:
- Which stream benefits from timeboxed sprints and a clear Sprint Goal?
- Which stream benefits from continuous flow and WIP limits?
- How could TDD, CI, and refactoring help with integration and quality?
Suggested reasoning pattern (do this mentally before checking your notes):
- New feature development often maps well to Scrum (sprints, Sprint Goals, Product Backlog).
- Unplanned support work often maps well to Kanban (continuous flow, WIP limits, pull system).
- Across both, apply XP practices (TDD, CI, refactoring, maybe pair programming) to reduce defects and integration pain.
After thinking it through, write one or two bullet points summarizing:
- How you would combine Scrum, Kanban, and XP.
- Which pain points each element is intended to solve.
Key Terms Review: Kanban, Flow, and XP
Flip these cards to reinforce the core concepts you need for the CAPM exam.
- Kanban
- A flow-based method for managing work that emphasizes visualizing workflow, limiting work-in-progress, and improving flow using metrics like cycle time and throughput.
- Work-in-progress (WIP) limit
- A policy that sets the maximum number of work items allowed in a given workflow stage or column at one time, used to reduce multitasking and improve flow.
- Cycle time
- The amount of time from when work starts on an item until it is completed. It reflects how long the team actively works on the item.
- Lead time
- The total time from when a request is made until it is completed, representing how long a stakeholder waits from request to delivery.
- Throughput
- The number of work items completed per unit of time, such as items per week, used to understand and forecast delivery capacity.
- Extreme Programming (XP)
- An agile software development approach focused on technical excellence and frequent delivery, using practices like pair programming, test-driven development, continuous integration, and refactoring.
- Pair programming
- An XP practice where two developers work together at one workstation on the same code, frequently swapping roles to improve quality and share knowledge.
- Test-driven development (TDD)
- An XP practice where developers write an automated test before writing production code, following a Red → Green → Refactor cycle to drive design and ensure test coverage.
- Continuous integration (CI)
- An XP practice where developers integrate code into a shared repository frequently, with automated builds and tests run on each integration to detect issues early.
- Refactoring
- The process of improving the internal structure of code without changing its external behavior, making it cleaner and easier to maintain.
- Scrum vs Kanban: key difference
- Scrum uses timeboxed sprints, defined roles, and events; Kanban uses continuous flow, visual boards, and explicit WIP limits with no required roles or timeboxes.
Key Terms
- Scrum
- An agile framework that uses timeboxed sprints, defined roles (Product Owner, Scrum Master, Developers), and events to deliver increments of value.
- Kanban
- A flow-based method for managing work that emphasizes visualizing workflow, limiting work-in-progress, and improving flow using metrics like cycle time and throughput.
- Lead time
- The total time from when a request is made until it is completed, representing how long a stakeholder waits from request to delivery.
- Cycle time
- The amount of time from when work starts on an item until it is completed, reflecting how long the team actively works on the item.
- Throughput
- The number of work items completed per unit of time, such as items per week, used to understand and forecast delivery capacity.
- Pull system
- A way of managing work where new items are started only when there is available capacity, often controlled by WIP limits.
- Refactoring
- Improving the internal structure of code without changing its external behavior, making it cleaner, simpler, and easier to maintain.
- Kanban board
- A visual representation of workflow, typically with columns for stages like To Do, In Progress, and Done, and cards representing individual work items.
- Flow-based work
- An approach that focuses on how work items move through a system, aiming for smooth, predictable flow rather than fixed-length iterations.
- Pair programming
- An XP practice where two developers work together at one workstation on the same code, frequently swapping roles to improve quality and share knowledge.
- Extreme Programming (XP)
- An agile software development approach focused on technical excellence and frequent delivery, using practices such as pair programming, test-driven development, continuous integration, and refactoring.
- Continuous integration (CI)
- An XP practice where developers integrate code into a shared repository frequently, with automated builds and tests on each integration to detect issues early.
- Work-in-progress (WIP) limit
- A policy that sets the maximum number of work items allowed in a given workflow stage or column at one time, used to reduce multitasking and improve flow.
- Test-driven development (TDD)
- An XP practice where developers write an automated test before writing production code, following a Red → Green → Refactor cycle.