Kanban Agile Development:
The Complete Guide to Agile Kanban Boards

2. What Is Agile Kanban?

Agile is a set of values and principles for building products in small, frequent increments, collaborating closely with customers and adapting to change. It was written down in the Agile Manifesto in 2001 by seventeen software practitioners, who valued individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.

Kanban (Japanese for "signboard" or "visual card") began on the factory floor at Toyota, where Taiichi Ohno used cards to signal when a station needed more parts. Production was pulled by real demand instead of being pushed by a forecast. In the late 2000s David J. Anderson adapted these ideas to knowledge work, and his book Kanban: Successful Evolutionary Change for Your Technology Business (2010) defined what is now called the Kanban Method, today maintained by Kanban University.

Agile Kanban — often called agile development Kanban when used by software teams — combines the two. There are no mandatory sprints, roles or ceremonies. You start with the process you already have, make it visible, limit how much is in progress, and improve step by step.

Why agile teams choose Kanban

• Continuous delivery: features ship as soon as they are done, not at the end of a sprint or project.
• Flexibility: priorities can change at any time; the next card pulled is always the most valuable one.
• Focus: WIP limits stop multitasking, reduce context switching and expose bottlenecks.
• Transparency: everyone — developers, product managers, stakeholders — sees the same board.
• Predictability: flow metrics such as cycle time and throughput make delivery forecasts data-driven.
• Easy adoption: no reorganisation needed. Kanban is evolutionary, so teams keep their roles and titles.

The Kanban Method's guiding principles

1. Start with what you do now. Map your existing workflow rather than adopting a new one overnight.
2. Agree to pursue improvement through evolutionary change. Small, continuous changes beat big-bang transformations.
3. Encourage acts of leadership at every level. Anyone can spot a bottleneck and suggest a fix.
4. Focus on the customer, manage the work, not the people. Let the system organise itself around flow.

3. Anatomy of an Agile Kanban Board

An agile Kanban board is a visual model of your workflow. Whether it is a whiteboard with sticky notes or a digital board in an app like PlanBoards, it contains the same building blocks.

Columns (lists)

Each column is a stage in your workflow. A typical agile software board uses Backlog → Ready → In Progress → Code Review → Testing → Done, but the right columns are the ones that mirror how work really moves in your team. Many teams split a stage into "doing" and "done" sub-columns so it is obvious when a card is waiting to be pulled.

Cards

A card is one unit of work: a user story, a bug, a technical task or an experiment. Good cards are small (a few days of work at most) and contain everything needed to finish them — description, acceptance criteria, checklist, due date, priority, owner and attachments such as designs or logs.

WIP limits

A WIP limit is the maximum number of cards allowed in a column at the same time. When "In Progress" has a limit of 3 and already holds 3 cards, nobody starts something new; the team helps finish what is already started. This simple rule is what turns a to-do board into a Kanban system.

Commitment and delivery points

The commitment point is where the team agrees to deliver an item (usually when a card leaves Ready). The delivery point is where the item reaches the customer. The time between them is your cycle time; the time from request to delivery is lead time.

Swimlanes and classes of service

Horizontal rows or colour codes separate types of work. Common classes of service are: Expedite (urgent, e.g. a production outage — usually a WIP limit of 1), Fixed date (has a hard deadline), Standard (normal priority, first in first out) and Intangible (tech debt, refactoring, tooling).

Explicit policies

Written rules — shown at the top of each column or in a pinned card — such as the Definition of Ready ("has acceptance criteria and design attached") and Definition of Done ("code reviewed, tested, released, documented").

4. Agile Kanban Board Examples

Below are six real-world agile Kanban board examples you can copy. Each one was built in PlanBoards using coloured lists, labels, checklists, due dates and image thumbnails.

Example 1: Agile software development board

The classic board for a product team building a mobile or web app. Work flows from Backlog to Done, with WIP limits on the stages where work tends to pile up (development, review and testing). Bugs get a red label, features a blue one, and urgent items a flag.

• Lists: Backlog · Ready · In Progress (WIP 3) · Code Review (WIP 2) · Testing (WIP 2) · Done
• Best for: product teams of 3–9 developers shipping continuously

See the agile software development board at the top of this page.

Example 2: Specify · Implement · Validate board

A board inspired by the workflow described in Eric Brechner's Agile Project Management with Kanban (see section 8). Each step has an "Active" and a "Done" area, so the team instantly sees which items are finished in one step and ready to be pulled into the next.

Example 3: Bug triage and support board

Incoming bug reports are triaged by severity, an Expedite list with a WIP limit of 1 handles critical incidents, and everything else flows through Fixing and Verify. Priority labels (Critical, High, Medium, Low) make the board easy to scan.

Example 4: Lean product discovery board

Product managers use this board to test ideas before building them. Each card is a hypothesis that moves through Build MVP → Measure → Learn. Validated ideas go to delivery; invalidated ones are dropped early — the Lean way to avoid building features nobody wants.

Example 5: DevOps release pipeline board

Release managers and DevOps engineers track each build from Ready to Release through Staging, Canary rollout, Production and Monitoring. Tight WIP limits on Staging and Canary ensure only one risky change is in flight at a time.

Example 6: Waterfall phases on a Kanban board

Not every project can drop its phases. Agencies and enterprise teams often keep Waterfall stages (Requirements, Design, Build, Test, Deploy) as lists but run them with Kanban rules — visible cards, WIP limits and pull. It is the gentlest first step from Waterfall to agile (see section 13).

5. The 6 Core Practices of Agile Kanban

The six core practices of agile Kanban are visualize the workflow, limit work in progress, manage flow, make policies explicit, implement feedback loops, and improve collaboratively.

1. Visualize the workflow

Put all work on the board — features, bugs, support requests, technical debt. Hidden work is the main reason teams miss deadlines. Use colours and labels so the type and priority of a card are visible at a glance.

2. Limit work in progress

Set a WIP limit for every active column. A good starting point is roughly the number of people working in that stage, then lower it until work flows smoothly without anyone sitting idle. Limiting WIP is the single biggest lever for shorter cycle times.

3. Manage flow

Watch how cards move, not how busy people are. Look for cards that sit too long in one column, columns that are always full and columns that are always empty. Each one points to a bottleneck worth fixing.

4. Make policies explicit

Write down how work is done: what "Ready" means, what "Done" means, who can pull from which column and how expedite items are handled. Explicit policies remove guesswork and make improvement discussions objective.

5. Implement feedback loops

Kanban suggests regular cadences: a short daily stand-up in front of the board (walk the board from right to left, focusing on blocked items), a replenishment meeting to decide what enters Ready, delivery planning, and periodic service delivery, operations and risk reviews. Small teams can combine these into a weekly review.

6. Improve collaboratively, evolve experimentally

Use data and simple models (Lean, Theory of Constraints, Little's Law) to propose changes, try them, measure the effect and keep what works.

6. Agile Project Management with Kanban

Agile project management with Kanban applies the same board and flow principles to whole projects, not only to developers. Product launches, website rebuilds, marketing campaigns or client work all fit. The project manager's job shifts from assigning tasks and chasing status to keeping the flow healthy, removing blockers and managing priorities in the backlog.

How to set up agile project management with Kanban — step by step

1. Define the scope of the board. One team or one product per board. If several teams share a project, give each team its own board and add a portfolio board with one card per epic.
2. Map your workflow into lists. Write down the stages work actually passes through. Start simple — four to six lists are enough.
3. Create the backlog. Break the project into epics, then into small user stories or tasks. Each becomes a card with a clear outcome.
4. Add WIP limits. Put the limit in the list name (e.g. "In Progress (3)") so everyone sees it.
5. Define policies. Agree on Definition of Ready and Definition of Done; add them as a pinned card in the first list.
6. Prioritise continuously. The product owner or project manager keeps the top of Backlog/Ready ordered by value, urgency and risk.
7. Run a daily stand-up at the board. Ask: what is blocked, what is close to done, where is work piling up?
8. Measure and forecast. Track cycle time and throughput, then use them to answer "when will it be done?" (see section 7).
9. Review and improve. Hold a short retrospective every few weeks and adjust columns, limits and policies.

Managing deadlines and stakeholders

Kanban has no sprint commitment, but it is very good at deadlines. Mark fixed-date items with a due date and a dedicated colour, track how many cards remain in the release, and divide by your weekly throughput to see whether the date is realistic. Because the board is always current, stakeholders can check progress themselves — in PlanBoards you can even send a single card to a client or manager as a public link, without them installing the app. See Sharing Cards.

Scaling Kanban across teams

• Team boards for day-to-day work, each with its own WIP limits.
• A portfolio or program board where each card is an epic or initiative, with lists such as Proposed, Analysing, In Delivery, Released.
• Dependencies shown with labels or linked cards, discussed in a weekly cross-team sync.

Run the project as a flow

Colour-coded lists, cards with images, checklists and due dates – on Android, iPhone, tablet and desktop.

Free to use

7. Agile Kanban Metrics: Lead Time, Cycle Time, Throughput and CFD

Kanban replaces velocity and story points with flow metrics that measure real elapsed time and output: lead time, cycle time, throughput and work in progress.

Little's Law: Average cycle time = Average WIP ÷ Average throughput. If your team finishes 10 cards per week and has 20 cards in progress, each card takes about 2 weeks. Cut WIP to 10 and — with the same throughput — cycle time drops to about 1 week.

Forecasting without estimates

Many Kanban teams stop estimating in story points altogether. If the last 8 weeks show a throughput of 6–9 cards per week and 40 cards remain for a release, the release is likely 5–7 weeks away. More advanced teams run Monte Carlo simulations on historical throughput to give a date with a confidence level ("85% chance by 12 March").

8. Eric Brechner's "Agile Project Management with Kanban"

Agile Project Management with Kanban is a practical, concise book by Eric Brechner, published by Microsoft Press (book page on O'Reilly). Brechner was a development manager on the Xbox engineering team at Microsoft, and earlier worked at Boeing, Silicon Graphics and NASA's Jet Propulsion Laboratory. The book is popular with software teams because it shows how a large engineering organisation actually ran Kanban, rather than describing it in theory.

What the book covers

1. Making the case to management — written as an open letter you can hand to your boss.
2. Kanban quick-start guide — how to set up a board and start in a week.
3. Hitting deadlines — planning and tracking date-driven work with Kanban.
4. Adapting from Waterfall — moving a plan-driven team to Kanban.
5. Evolving from Scrum — keeping what works in Scrum and adding flow.
6. Deploying components, apps and services — continuous delivery and release practices.
7. Using Kanban within large organisations — coordinating many teams and dependencies.
8. Sustained engineering — handling maintenance and bug-fix work (contributed by James Waletzky).
9. Further resources and beyond — Lean, Theory of Constraints and related reading.

Key ideas from Brechner's approach

• A simple, standard board. A wide Backlog column followed by Specify, Implement and Validate, each split into an active area and a "done" area, then Done. (Example 2 above follows this structure.)
• Pull criteria for every step. A card can only move on when it meets the written criteria for that step — a lightweight, explicit Definition of Done per column.
• The smallest WIP limits that keep everyone busy. Limits are derived from team size and how long each step typically takes, then tuned in practice.
• A daily stand-up focused on the board. The team moves cards and resolves problems, rather than giving individual status reports.
• Three ways to limit chaos. Brechner frames Waterfall, Scrum and Kanban as different answers to the same problem: Waterfall limits chaos by specifying everything up front and controlling change; Scrum limits it with time-boxed sprints; Kanban limits it directly by capping work in progress.

Who should read it? Development managers, team leads and project managers who want a hands-on, low-ceremony way to introduce Kanban — especially those coming from Waterfall or Scrum. If you prefer to learn by doing, set up the Specify · Implement · Validate board in PlanBoards and read the quick-start chapter alongside it.

9. Agile vs Scrum vs Kanban vs Lean vs Waterfall: How They Fit Together

Agile, Scrum, Kanban, Lean and Waterfall are not five versions of the same thing. Lean is a philosophy, Agile is a mindset, Scrum and Kanban are ways to practise that mindset, and Waterfall is a sequential plan-driven approach.

• Lean is a philosophy of maximising customer value and eliminating waste, born in Toyota's manufacturing system.
• Agile is a mindset — four values and twelve principles — for building software iteratively.
• Scrum and Kanban are frameworks/methods that put Agile (and Lean) into practice. Kanban draws most directly on Lean.
• Waterfall is a sequential, plan-driven approach: requirements, design, build, test and deploy happen one after another. Its classic description is usually traced to Winston Royce's 1970 paper — which, ironically, warned about the risks of a purely sequential process.

Which one should you use?

• Requirements change often and work arrives unpredictably (support, ops, maintenance, marketing) → Kanban.
• Building a new product with a dedicated team that benefits from a fixed rhythm → Scrum (or Scrumban).
• Scope, budget and requirements are fixed and well known (construction, hardware, compliance) → Waterfall, possibly with a Kanban board to manage the work inside each phase.
• You want to remove waste from any of the above → apply Lean principles.

10. Agile Scrum and Kanban: Differences, Similarities and Scrumban

Scrum and Kanban are the two most popular agile approaches, and both use a board. The difference is in how they limit work and when they deliver.

What Scrum and Kanban have in common

• Both are agile and empirical: inspect and adapt.
• Both break work into small pieces and make it visible.
• Both limit work in progress — Scrum indirectly, Kanban directly.
• Both rely on self-organising teams and continuous improvement.

Scrumban: combining agile Scrum and Kanban

Scrumban, popularised by Corey Ladas in his writing and book Scrumban, blends the structure of Scrum with the flow of Kanban. Teams keep useful Scrum events (planning, review, retrospective) but replace sprint commitments with WIP limits and on-demand planning: when the "Next Up" list drops below a threshold, the team holds a short planning session to refill it.

Choose Scrumban when your Scrum team is constantly interrupted by urgent work, sprints keep failing because priorities change mid-sprint, or you want to move from Scrum to Kanban gradually.

11. Agile Lean Kanban: Applying Lean Thinking to Software

Kanban is the most direct bridge between Lean and Agile. Lean thinking, summarised by James Womack and Daniel Jones, rests on five principles, each of which maps to a Kanban practice.

Mary and Tom Poppendieck translated Lean into Lean Software Development with seven principles: eliminate waste, build quality in, create knowledge, defer commitment, deliver fast, respect people and optimise the whole. They also identified seven forms of waste in software — and a Kanban board makes every one of them visible.

Agile, Scrum, Kanban and Lean in one team

Many mature teams use all four: Agile values guide decisions, Lean thinking drives waste reduction, Kanban manages the daily flow of work, and selected Scrum events (reviews and retrospectives) provide a rhythm for feedback. The Lean product discovery board in Example 4 shows this in practice: hypotheses are tested with a Build-Measure-Learn loop before they ever reach the development board.

12. Agile Kanban vs Waterfall

Waterfall plans everything up front and moves through phases in sequence. Agile Kanban delivers small pieces continuously and reprioritises at any time. Neither is always right — the choice depends on how much uncertainty your project has.

Can you combine Agile, Waterfall and Kanban?

Yes. Hybrid ("Water-Scrum-Fall" or "agile-waterfall") approaches are common in enterprises: high-level budgeting and milestones are planned Waterfall-style, while the work inside each phase is managed on a Kanban board. This gives management the predictability it needs and gives teams the flexibility to deliver incrementally. Example 6 above shows such a hybrid board.

Trade the phase gates for a board

Android, iPhone, tablet and desktop.

Free to use

13. How to Move from Waterfall to Agile Kanban

Because Kanban starts with what you do now, it is often the easiest agile approach for Waterfall teams. You do not need to retrain everyone or redesign roles before day one.

1. Map: create a list for each current phase — Requirements, Design, Build, Test, Deploy.
2. Visualize: add every deliverable and task as a card. Include the "invisible" work: approvals, meetings, rework.
3. Slice: break big deliverables into small pieces that can pass through all phases independently.
4. Limit: put WIP limits on the phases where work queues up (usually testing and approvals).
5. Pull: replace big phase gates with pull criteria per column, so pieces move forward individually.
6. Measure: start tracking cycle time and throughput, and review them every week or two.

Common pitfall: keeping huge "phase-sized" cards. If a card takes weeks to move, the board will not show flow. Aim for cards that can be finished in one to five days.

14. How to Run Agile Kanban in PlanBoards

PlanBoards is a visual Kanban app for Android, iPhone, tablet and desktop. Its colourful boards, rich cards and real-time sync make it a lightweight home for agile Kanban — for solo developers, startups and small teams. See Features and SME & Projects.

How to do it in PlanBoards

Quick start: your first agile Kanban board in 5 minutes

1. Create a new board called e.g. "Agile Development — App v1".
2. Add lists: Backlog, Ready, In Progress (3), Review (2), Testing (2), Done.
3. Add your top 10–20 backlog items as cards; label bugs and features in different colours.
4. Open each Ready card and add a checklist with your Definition of Done.
5. Pull the first three cards into In Progress — and start finishing before starting.

15. Agile Kanban Best Practices and Common Mistakes

The most useful agile Kanban habit is to stop starting and start finishing: help a teammate finish a card before pulling a new one, and treat a missing WIP limit as a to-do list rather than a Kanban system.

Best practices

• Stop starting, start finishing. Help a teammate finish a card before pulling a new one.
• Keep cards small. One to five days of work. Split anything bigger.
• Walk the board from right to left in stand-ups — closest to done first.
• Make blockers loud. Use a red label or flag and discuss blocked cards first.
• Limit the Expedite lane to one card. If everything is urgent, nothing is.
• Review metrics regularly. A monthly look at cycle time and the CFD reveals trends a daily view hides.
• Keep the board honest. If work happens outside the board, it does not get managed.

Common mistakes

• No WIP limits — without them it is just a to-do list with columns.
• Too many columns — every extra handoff is a queue. Start with five or six.
• Ignoring the limits "just this once" — the limit is most valuable exactly when it feels inconvenient.
• Measuring people instead of flow — utilisation targets increase WIP and slow delivery.
• Never changing the board — Kanban is evolutionary; revisit columns and policies regularly.

16. Agile Kanban Glossary

These are the terms used on an agile Kanban board, from the board itself to the metrics that describe how work flows.

Agile

A mindset for software development based on the 2001 Agile Manifesto: deliver working software in small, frequent increments and adapt to change.

Kanban

A method for managing knowledge work by visualising it on a board, limiting work in progress and improving flow. From the Japanese word for "signboard".

Kanban board

A board with columns (lists) for each workflow stage and cards for each work item.

WIP limit

The maximum number of work items allowed in a workflow stage at the same time.

Pull system

A system in which work is started only when there is capacity for it, rather than being assigned (pushed) regardless of capacity.

Lead time

The time from when a work item is requested until it is delivered to the customer.

Cycle time

The time from when work on an item starts until it is finished.

Throughput

The number of work items finished per unit of time, e.g. per week.

Cumulative flow diagram (CFD)

A stacked area chart showing how many items are in each workflow stage over time; used to spot bottlenecks.

Little's Law

Average cycle time = average WIP ÷ average throughput.

Class of service

A category that sets how a work item is prioritised, e.g. Expedite, Fixed date, Standard or Intangible.

Swimlane

A horizontal row on a Kanban board that separates types of work or teams.

Commitment point

The point on the board where the team commits to delivering a work item.

Definition of Done

The explicit criteria a work item must meet to be considered finished.

Scrum

An agile framework that delivers work in fixed-length sprints with defined roles and events.

Scrumban

A hybrid that combines Scrum events with Kanban's WIP limits and continuous flow.

Lean

A philosophy from the Toyota Production System focused on customer value, flow, pull and eliminating waste.

Waterfall

A sequential, plan-driven approach in which each phase (requirements, design, build, test, deploy) finishes before the next begins.

18. Sources and Further Reading

The comparisons and definitions on this page follow these public sources.

• Beck, K. et al. (2001). Manifesto for Agile Software Development.
• Schwaber, K. & Sutherland, J. (2020). The Scrum Guide.
• Kanban University. The Kanban Method.
• Kanban Guides. The Kanban Guide.
• Brechner, E. Agile Project Management with Kanban. Microsoft Press.
• Anderson, D. J. (2010). Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press.
• Ladas, C. Scrumban: Essays on Kanban Systems for Lean Software Development. Modus Cooperandi Press.
• Poppendieck, M. & Poppendieck, T. (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley.
• Womack, J. P. & Jones, D. T. (1996). Lean Thinking. Simon & Schuster.
• Wikipedia: Kanban (development) · Little's law · Lean software development · Waterfall model · Toyota Production System

Related pages: Features · SME & Projects · Personal · Sharing Cards · Pricing

Visualize your workflow. Limit your WIP. Ship continuously.

Build your first agile Kanban board with PlanBoards.

Free to use