Skip to main content
Agile Scrum – Complete Beginner to Advanced Guide
CHAPTER 10 Beginner

Kanban and Agile Boards

Updated: May 16, 2026
30 min read

# CHAPTER 10

Kanban and Agile Boards

1. Introduction

Scrum is powerful, but its rigid 2-week timeboxes are not perfect for every situation. Imagine an IT Support team dealing with live server crashes. They cannot wait for a "Sprint Planning" meeting to fix a broken database; they must react continuously. Or imagine a DevOps team whose work flows in an endless, unpredictable stream. For these scenarios, the Agile umbrella offers another heavyweight framework: Kanban. Born on the manufacturing floors of Toyota, Kanban is obsessed with visualizing work, identifying bottlenecks, and maximizing flow. In this chapter, we will master Kanban. We will learn how to build visual Agile boards, enforce Work-In-Progress (WIP) limits, and achieve Continuous Delivery without the need for strict Sprints.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Define the origins and core philosophy of Kanban (Lean Manufacturing).
  • Compare and contrast Kanban frameworks with Scrum frameworks.
  • Design an effective visual workflow (The Kanban Board).
  • Understand and implement Work-In-Progress (WIP) limits.
  • Analyze bottlenecks to achieve Continuous Flow.

3. What is Kanban?

Kanban is a Japanese word meaning "visual signal" or "card." It is an Agile framework based on Lean principles.
  • The Philosophy: Stop starting, start finishing.
  • The Mechanics: Unlike Scrum, Kanban has no required roles (no Scrum Master), no required timeboxes (no Sprints), and no required estimation (no Story Points). It is a continuous flow of work. You pull a ticket from the backlog, finish it, and immediately deploy it.

4. Workflow Visualization (The Board)

The core of Kanban is the Board. Every piece of work must exist as a card on this board. The board is divided into vertical columns representing your exact workflow.
  • Basic Board: To Do -> In Progress -> Done
  • Software Board: Backlog -> Analysis -> Development -> Code Review -> QA Testing -> Deployed
*Transparency:* If a developer looks at the board, they instantly know the state of the entire project without asking a single question.

5. Work-In-Progress (WIP) Limits

This is the magic of Kanban. A WIP Limit is a hard cap on how many cards can exist in a specific column at one time.
  • The Problem: Developers start coding 5 different features at once. Context switching destroys productivity, and nothing gets finished.
  • The WIP Solution: You set a WIP limit of '3' on the Development column. If there are 3 cards in development, a coder *cannot* pull a new ticket from the Backlog. They are forced to help finish the existing tickets or move them to Code Review before starting new work.
  • The Result: WIP limits force teams to finish existing work before starting new work, dramatically increasing the speed of delivery (throughput).

6. Managing Bottlenecks

WIP limits make bottlenecks instantly visible.
  • If the QA Testing column has a WIP limit of 2, and it is full, developers will finish code and try to move it to QA. But they can't. The Code Review column piles up. The whole board freezes.
  • *The Agile Response:* The developers stop coding new features. They swarm the QA column, helping the QA engineers test the software until the bottleneck is cleared. Kanban optimizes the *entire system*, not individual efficiency.

7. Diagrams/Visual Suggestions

*Kanban Board with WIP Limits*
txt
1234 
[ Backlog ] | [ Development (WIP: 3) ] | [ Code Review (WIP: 2) ] | [ Testing (WIP: 2) ] | [ Deployed ]
   Card 1   |         Card 4           |          Card 7          |       Card 8         |    Card 10
   Card 2   |         Card 5           |                          |       Card 9         |
   Card 3   |         Card 6           |                          |    [BOTTLENECK]      |

*(In this example, Testing is maxed out. Development is maxed out. No new cards can be pulled from the Backlog until Testing clears).*

8. Scrum vs. Kanban (Scrumban)

  • Scrum: Resets every 2 weeks. Rigid roles. Best for building complex new products where the roadmap changes frequently based on feedback.
  • Kanban: Continuous flow. No resets. Best for maintenance, operations, IT support, or highly mature continuous-delivery teams.
  • Scrumban: Many modern software teams combine them. They use the Roles and Ceremonies of Scrum (Sprints, Dailies, Retrospectives) but utilize Kanban Boards and WIP limits to manage the daily execution within the Sprint.

9. Common Mistakes

  • The Infinite "In Progress" Column: A team uses a Kanban board, but puts no WIP limits on their columns. By Friday, they have 40 tickets sitting in "In Progress" and 0 in "Done." This is just a to-do list, not a Kanban system. Without WIP limits, Kanban provides zero value.

10. Mini Project: Design a Support Kanban Board

Scenario: You manage an IT Helpdesk. Tickets come in unpredictably.
  1. 1. Design the columns: New Tickets -> Triaged -> Investigating -> Waiting on Customer -> Resolved.
  1. 2. Apply WIP limits based on your 2-person team. Limit Investigating to 4 (2 per person).
  1. 3. Rule: If Investigating hits 4, the team must resolve a ticket before looking at a New Ticket.

11. Practice Exercises

  1. 1. Explain the philosophy of "Stop starting, start finishing." How do Work-In-Progress (WIP) limits mathematically enforce this philosophy?
  1. 2. Compare the core structural differences between Scrum (Iterative) and Kanban (Continuous Flow).

12. MCQs with Answers

Question 1

What is the primary purpose of establishing Work-In-Progress (WIP) limits on a Kanban board?

Question 2

Which Agile framework is most appropriate for an IT Operations team that receives an unpredictable, continuous stream of high-priority server crash tickets every day?

13. Interview Questions

  • Q: A Kanban board shows 0 tickets in Development, but 15 tickets piled up in the "QA Testing" column. The entire system is blocked. As an Agile coach, what do you instruct the Developers to do?
  • Q: Contrast the time estimation approaches of Scrum (Story Points / Velocity) with Kanban (Cycle Time / Lead Time).
  • Q: Is it possible to use a Kanban board without implementing WIP limits? What is the architectural consequence of doing so?

14. FAQs

Q: Can we release software every day with Kanban? A: Yes! This is called Continuous Delivery. Because Kanban has no 2-week Sprint boundaries, the second a ticket hits the "Done" column, it can be pushed to production. High-performing Kanban teams deploy to production dozens of times a day.

15. Summary

In Chapter 10, we explored the visual, continuous flow of Lean manufacturing. We learned that while Scrum utilizes timeboxes to manage complexity, Kanban relies entirely on visual workflow mapping and strict Work-In-Progress (WIP) limits. By forcing teams to "stop starting and start finishing," Kanban eliminates the toxic waste of context-switching and brutally exposes system bottlenecks. Whether utilized as a standalone framework for continuous support teams, or combined with Scrum as "Scrumban," the Kanban board is the ultimate tool for achieving high-speed continuous delivery.

16. Next Chapter Recommendation

We know the frameworks and the workflows. Now we must look at the software applications that actualize them. Proceed to Chapter 11: Agile Project Management Tools.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Previous Chapter Sprint Review and Retrospective
Next Chapter Agile Project Management Tools

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·

Explore More

📖 Related Tutorials 5

🎥 Related Videos 1