What is kanban?
Kanban (看板) means "signboard" or "billboard" in Japanese. It was developed by Taiichi Ohno at Toyota in the 1940s as a scheduling system for lean manufacturing - a way to signal when more work should be pulled into the system, based on capacity, not a push schedule.
In software, kanban was popularised by David J. Anderson in the 2000s as a way to visualise and manage knowledge work. The idea is the same: instead of telling people what to work on, you make the flow of work visible and let people pull tasks when they have capacity.
The core insight: make work visible. If you can see what's in progress, what's blocked, and what's waiting, you can improve the system - not just the individuals.
A kanban board is the primary tool. Work items (cards) move left to right across columns that represent workflow states. At a glance, anyone on the team can see the complete state of the work.
How a kanban board works
A kanban board has three fundamental elements: columns that represent workflow states, cards that represent individual work items, and flow - the movement of cards from left to right as work progresses.
Cards start in To Do on the left. As a developer picks up work, the card moves to In Progress. If something is waiting on an external dependency, it goes to Blocked. When work is complete, it lands in Done.
The flow of progress is left to right: a card shouldn't slide back from Done to In Progress - if finished work needs rework, it's treated as a new piece of work. A card moves into Blocked when it stalls and back into In Progress the moment it's unblocked. That keeps the flow unambiguous and the board honest.
The four columns
Runer uses four columns that cover the lifecycle of any story. Here's what each one means and how to use it.
Ready to be worked on
Stories that have been planned and scoped but not yet started. This is your team's queue. The order in To Do represents priority - work is pulled from the top.
Actively being worked on
Stories someone is actively building right now. The cardinal rule of kanban applies here: limit your work in progress. A developer working on four things at once is effectively working on none of them well.
Waiting on something external
Stories that were in progress but are now stuck - waiting on a design decision, a third-party API, a review, or any other external dependency. Blocked is a signal, not a holding area.
Complete and verified
Stories that are shipped, reviewed, and accepted. Done means really done - not "code merged" but "working in production" (or whatever your team's definition of done is). Agree on this definition before you start.
Kanban principles
Kanban is more than a board - it's a set of principles for managing the flow of work. You don't need to implement all of them to benefit from kanban, but understanding them helps you use the board more effectively.
Visualise the work
Make all work visible on the board - not just the happy-path tasks, but also bugs, tech debt, meetings, and ad-hoc requests. If it takes time, it belongs on the board.
Limit work in progress
Set a cap on how many items can be In Progress at once. WIP limits force the team to finish before starting. They expose bottlenecks and reduce the cost of context switching.
Manage flow
The goal is a smooth, continuous flow of work - not big batch releases. Monitor how long cards take to move from To Do to Done (cycle time) and look for patterns in what slows things down.
Make policies explicit
Agree on what "In Progress" means, what "Done" means, and when to move a card. Written-down rules eliminate ambiguity and help new team members contribute immediately.
Improve continuously
Use the board as feedback. Review blockers in your retrospective. If a particular step is always full, ask why. Kanban is a system for learning about your process, not just tracking tasks.
Pull, don't push
Work is pulled by whoever has capacity, not pushed by a manager's schedule. This self-organisation reduces overload and increases ownership - people choose what to work on based on priority and their own capacity.
Kanban vs Scrum
Kanban and Scrum are both agile frameworks, but they take different approaches to organising work. Neither is strictly better - the right choice depends on the nature of your work.
Scrumban is the middle ground. A hybrid many teams land on: Scrum's planning cadence and retrospectives, run through a kanban board with WIP limits and continuous flow. The three sit on a spectrum - you don't have to pick a side.
Kanban and story mapping
Story mapping and kanban answer different questions. Story mapping asks: "What are we building and why?" Kanban asks: "What's the current state of the work?" Used together, they give a complete picture.
One source of truth
The same stories appear in the story map, the kanban board, and the release planner. Update a status once and it's reflected everywhere - no synchronisation needed.
Context for execution
When a developer picks up a card on the kanban board, they can flip to the story board to see where that story fits in the bigger picture - which activity it belongs to, what comes before and after.
Release-scoped focus
Filter the kanban board to a single release and you get a focused view of exactly what's shipping next. No noise from future releases cluttering the board.
A common pattern: run a story mapping session at the start of a project or quarter to set direction, then use the kanban board daily to track execution. The map is the strategy; the board is the tactics.
Kanban in Runer
Runer's kanban view is a live lens over your story map. Every story you create on the story board immediately appears as a card on the kanban board. There's nothing to import or sync.
Four status columns
To Do, In Progress, Blocked, and Done. Drag any card to change its status - the change is reflected instantly on the story board and releases view.
Filter by release
Focus the board on what's shipping in the current release. All future-release cards are hidden, so the team can concentrate on what matters now.
Drag to update status
Drag a card from any column to any other. The status updates instantly and persists. Marks the story as done on the releases progress bar too.
Further reading
The sources below shaped the ideas on this page. If you want to go deeper, these are the primary references.
Ohno's original account of the Toyota Production System, the manufacturing philosophy that kanban grew out of. The book explains pull-based scheduling, just-in-time production, and the idea of making problems visible - principles that map directly to software kanban.
The foundational text for software kanban. Anderson adapted the manufacturing concept for knowledge work and defined the core practices: visualise the workflow, limit WIP, manage flow, make policies explicit, and improve collaboratively. This is where the software kanban principles described in this guide originate.
The Poppendiecks translated Toyota's lean manufacturing principles into software development practice. Their work established the intellectual bridge between Ohno's factory floor system and the kanban boards used by software teams today.
The paper that coined "dual-track agile" - the practice of running discovery and delivery in parallel. Later popularised by Jeff Patton and Marty Cagan, this is the model behind pairing a kanban delivery board with a story mapping discovery process.