█
LastWrite
  • > Curriculum
  • > Pricing
  • > For Educators
  • > About
  • > Contact
Log InGet Started

Questions, concerns, bug reports, or suggestions? We read every message, write to us at [email protected].

More ways to reach us →
LastWrite

Structured computer science lessons for aspiring developers and security professionals.

[email protected]

(201) 785-7951

Mon–Fri, 9 AM–5 PM EST

Learn

  • Curriculum
  • Pricing

Company

  • About
  • For Educators & Schools
  • Contact Us

Legal

  • Terms of Service
  • Privacy Policy
© 2026 LastWrite. All rights reserved.
Curriculum/Software Engineering/Agile and Engineering Process/Kanban
30 minBeginner

Kanban

After this lesson, you will be able to: Explain Kanban's principles, set up a board with WIP limits, and decide when Kanban fits a team better than Scrum.

Kanban is the second-most-used Agile framework. Where Scrum is sprint-based and committed, Kanban is flow-based and continuous. Knowing both expands the choices you can make.

Prerequisites:Scrum

The core Kanban idea

Visualise the work (a board: Backlog → Todo → In Progress → Review → Done). Limit work in progress (WIP). Each column has a cap; you can't pull a new item until you've finished one. Measure flow (how long does an item take from Todo to Done?). Improve continuously, like Scrum's retros but more often.

Why WIP limits matter

Without WIP limits, everyone starts five things at once, nothing ships fast, context-switching destroys focus. WIP limits force focus: you can't pull a new card until you've moved one. Counter-intuitive result: lowering WIP often INCREASES throughput, because work flows faster when fewer things are in flight. Set WIP limit at ~team size, lower in 'In Progress' (e.g. one in-progress per dev), looser in 'Review' (anyone can review).

Scrum vs Kanban: when to pick which

Scrum: best for product work with clear sprint goals and stakeholder cadences. Roadmaps map well to sprints. Kanban: best for ops, support, and on-call rotations where work arrives unpredictably. Also good for bug-fix-heavy teams. Hybrid (Scrumban): a board with WIP limits, plus a weekly cadence for retros and demos. Used at many product teams in 2026. Pick the one whose rhythm matches the work, not the other way around.

Set up a Kanban board in 15 minutes

Linear, GitHub Projects, Trello, or Jira; the tool is secondary.

  1. 1

    Create columns: Backlog, Todo, In Progress, Review, Done

  2. 2

    Set WIP limits per column (visible in the UI): Todo = 8, In Progress = 4, Review = 3

  3. 3

    Move cards left-to-right. Once a card moves, the next person pulls

  4. 4

    Measure cycle time: average time from Todo → Done for the last 20 cards. This is your flow metric.

  5. 5

    Review the board in a weekly 30-min meeting. Look for: cards stuck in one column, WIP limits being exceeded, repeating bugs

Common mistakes only experienced engineers avoid

Setting no WIP limits. The board becomes a wishlist; nothing flows. Setting WIP limits too high. If the limit is never hit, it's not limiting anything. Treating Kanban as 'Scrum but no sprints'. It's a different philosophy; pulling work as capacity allows is the whole point. Forgetting cycle-time measurement. Without it, you can't tell if your changes improved anything. Letting cards age silently. A card stuck in Review for two weeks is a bug; investigate it like one.

Quick Check

Your team supports a product 24/7; tickets arrive at unpredictable rates. Sprints feel forced. What fits better?

Pick the framework that matches the work.

Sign in and purchase access to unlock this lesson.

Sign in to purchase
←Scrum
Back to Agile and Engineering Process
Writing Good Tickets and Estimation→