Kanban Board & Flow Metrics

What this tool does

CM8-239 runs a Kanban board and the flow metrics underneath it. You record one card per work item — its column, its owner, when it was raised, when work started and when it finished. The tool draws the board, holds the WIP limits you set, flags ageing items, calculates cycle time, lead time and throughput, and prints the lot as a report.

It suits any team that pulls work from a queue: maintenance, support, engineering, internal IT. It is not a Gantt chart — a Gantt says what should happen and when; a board says what is happening now and how fast it moves. Everything runs inside this single file: no account, no upload, no network request.

Kanban is three practices, and the board is the least important

• Visualise the work. Every item on one board. Work you cannot see is work you cannot manage.
• Limit work in progress. Cap how many items may sit in a column at once, and hold the cap. Most teams skip this, and it is where nearly all the benefit lives.
• Manage flow. Watch how long things take and where they queue, then change the system.

Be honest about the first: a board on its own changes nothing. A team with a beautiful board, forty cards and no limits has built a tidy picture of chaos. The board exists to make the other two possible.

WIP limits — the counter-intuitive part

Here is the claim people refuse to believe until they have seen it: starting less finishes more. Not more per person, not more effort — more finished work from the same team in the same week. The arithmetic is short.

Suppose your team finishes three items a week. With twelve in progress, the average item takes twelve ÷ three = four weeks from start to finish. Cut work in progress to six and, as long as throughput holds, the average takes two weeks. The team does the same amount of work; each item simply spends less of its life waiting behind other items.

The obvious objection is that throughput will not hold — surely doing fewer things at once finishes fewer? In practice the opposite happens, for two reasons. The first is queueing: most of an item's life is spent waiting rather than being worked on, so another item in the pot adds waiting to everything already there and adds no capacity at all. The second is context switching: every time somebody puts one job down and picks another up they lose the thread — where they had got to, what they had ruled out, which part is fiddly. Two jobs at once cost more than twice one job. So limits usually raise throughput rather than lower it.

The effect that matters most is not speed, though. A limit forces a decision: when In progress is full and something new arrives, somebody has to say out loud what will not be worked on. Without a limit that conversation never happens. Set the In progress limit below the number of people — a team of five with a limit of five has no limit at all — and limit the review column too, because review queues fill quietly: work in review feels finished to whoever did it and is not finished at all to whoever is waiting.

The columns, and why Blocked is one of them

• Backlog — raised, not committed. Nothing here is a promise.
• Ready — committed, waiting for a slot. Keep it short, or it is a second backlog.
• In progress — actively being worked. This column carries the important limit.
• Review / check — done, waiting on somebody else to verify, sign or accept it.
• Blocked — cannot proceed, for a reason outside the team's control.
• Done — finished and accepted, on the customer's definition.

Most tools mark blocked work with a flag on the card. Making it a column is better, because it makes the cost visible: a flagged card sits quietly in In progress looking like work, while a column of three blocked cards is a hole in the board somebody has to explain. This tool wants a blocker note first, because "blocked" without a named obstacle and someone who can clear it is not a status, it is a shrug. Blocked items keep ageing here, deliberately: the customer is still waiting, and stopping the clock is the commonest way teams flatter their own numbers.

Classes of service

• Standard — the normal queue, taken in order. Most work, most of the time.
• Expedite — jumps the queue, and everything else waits. For work costing money or stopping people right now.
• Fixed date — must land by a date set by an inspection, certificate, season or contract. Not urgent now; urgent later, and the trick is starting early enough. This tool requires the date.
• Intangible — improvement work with no deadline and no complaining customer: tooling, documentation, cleaning up how the work is done. It always loses to a breakdown unless protected.

One rule matters more than the rest: expedite must be rare. If more than roughly one item in ten is expedited, the class has stopped meaning anything — it has become the standard class, and genuine emergencies have nothing left to escalate to. A large red slice on the donut chart usually means the queue is not trusted.

Cycle time, lead time and throughput

Lead time is the honest number: it starts the moment somebody asks, includes every day the item spent in the backlog being ignored, and is usually far larger than teams expect. Cycle time starts when work actually begins; it is what you control most directly and what responds to WIP limits. The gap between the two is your queue — if lead time is thirty days and cycle time is four, twenty-six days were spent waiting to be started, and working harder will not touch them.

Throughput is a plain count of items finished per period — unglamorous, and the only one of the three you can forecast with. All three depend on the start date being real: set it to the date the item was raised because that is easier, and cycle time simply becomes lead time. This tool will not accept an item in In progress, Review or Done without one.

Ageing work in progress

If you take one thing from this tool, take this. Ageing work in progress is the most actionable signal on any board — the only one that reports trouble while you can still act on it. Cycle time is a post-mortem: it says how long finished items took, which is always late. Ageing says, today, which unfinished items are already in difficulty.

An item that has sat for thirty days is not thirty days of progress. It is a queue with a name. Something happened to it — it was bigger than it looked, it is quietly blocked, its owner moved on, or nobody has admitted it should be dropped. All four are worth knowing and none shows up in an average. Set the ageing threshold slightly above your typical cycle time; anything past it is drawn red. Treat a red card as a question, not a scold: what does this need, and who can give it?

The stand-up, read right to left

Walk the board from the right-hand end — from Done back toward Backlog — not person by person. Reading right to left asks the only question that matters: what is closest to finished, and what does it need? Going around the room instead asks everyone what they are starting, which is how boards fill up. Five useful minutes: clear anything in Review; deal with anything Blocked, by name and with an owner for the obstacle; ask what the oldest card in progress needs; only then see whether a slot is free. Finish before you start.

Forecasting from throughput

Teams spend a great deal of effort estimating individual items and are rarely better for it. A cheaper method: take the range of items finished per week over the last two or three months and divide the remaining items by it. Thirty items left at three to five a week is six to ten weeks — a range, which is the correct shape of an honest forecast, and it works because item sizes average out over enough cards.

Two warnings. It only holds if the future looks like the past, so a team that has just lost half its people cannot forecast from last quarter. And a rate from three finished cards is arithmetic, not evidence — plan against the spread, which is why the longest time is printed beside every average.

FAQ

How many columns should a board have? As few as you can bear. Every extra column is a handover, and handovers are where time disappears.

What if an item goes backwards? Move it back and leave the dates alone. Work returning from review is normal; if it happens constantly, the definition of finished is not agreed.

What counts as Done? Whatever your customer would accept, agreed in advance. "Finished apart from the paperwork" is how a review column becomes a swamp.

Can one board hold several teams? It can, but the WIP limits stop meaning anything. Use the board field and the filters.

Saving your work

Items, settings and the report header are written to this browser's local storage as you type, and the toolbar shows the time of the last save. That storage belongs to one browser on one computer: another browser, a private window or a clean-up tool will not have it. Treat Export .json as the real save — one file containing everything, which Import .json restores anywhere. Export CSV gives you the register for spreadsheet work. Reset asks twice, then erases everything. There is no undo.

Accuracy & disclaimer

The arithmetic here is subtraction and counting, done faithfully. Everything that matters sits underneath it. The board reflects what people actually move: a card nobody updates measures nothing, a start date entered as a formality turns cycle time into lead time, and an item parked in Done without being accepted inflates throughput. Cycle and lead times from a handful of finished items are indicative rather than statistical — one unusual item moves the average a long way, which is why the longest figure is printed beside it. WIP limits, ageing thresholds and classes of service are policies you choose; this is a measurement aid, not management advice.