Kanban on the shop floor WIP limits Measuring lead time

Custom Kanban software development

You can build a board with three columns and coloured cards in an afternoon. A board that the shop floor actually uses afterwards is a different matter: the columns have to follow the real process, waiting time has to be visible rather than hidden in a column called "in progress", and nobody should track the same work item twice. Appfront builds custom kanban software for work that flows through a department: requests, reports, orders, repairs and case files, even when there is no project behind them.

Free consultation Off-the-shelf tool or custom development?

What makes kanban on the shop floor different

Kanban comes from manufacturing, where a card only moves up once there is space downstream. That origin explains why the board you know from software teams often doesn't fit a department handling requests, reports or orders. With a project you steer by a plan with phases, milestones and a budget. With kanban you steer by flow: how much work is under way, how long it takes from arrival to completion, and where things stand still. The plan doesn't disappear, but the board answers different questions than a schedule does.

Individual work also behaves differently from project work. It arrives in varying volumes, is too small to plan and too big to do in between other things, and for most of its time it waits: for a customer's reply, for a part, for the one colleague who is allowed to approve. Anyone who pushes this kind of work into a project tool ends up with hundreds of items carrying a start and end date that nobody maintains. Anyone who pushes it into a spreadsheet can see the status, but not how long something has been sitting somewhere, and certainly not why.

The situations this applies to look alike, regardless of industry. A service desk that takes in requests and routes them to teams. An back-office team that checks, completes and releases orders. A workshop where repairs come in and go out, and where waiting for parts determines the lead time. A team handling cases with a statutory or contractual deadline. In all of these, the work consists of separate items with a start and an end, and the question from management is always the same: where is the delay, and how much can we take on?

Are you in the right place? This page is about flow and lead time for individual work items. If you want to steer a single project, with phasing, scheduling, hours and budget, you need custom project management software. If you need to choose between projects and weigh capacity across them, you're one level above this page. If the process involves strict routing, forms and decision rules that the system must enforce, look at a custom BPM platform.

The board is the process

Columns aren't labels but real steps, each with its own queue, an owner and an agreement about when work may move on.

Waiting takes up most of the time

In many processes an item sits idle for longer than it is actively worked on. Only a board that shows waiting separately makes this visible.

Pulling rather than pushing

Nobody has work pushed onto them. New work only comes in when there is room further along, and a WIP limit is what enforces that.

Columns that follow the actual process

The standard layout of to do, in progress and done isn't wrong, it's just empty. Everything you want to know is hidden in the middle column. In a department, the real path usually looks more like this: accepted, checked for completeness, assigned to a team, in progress, reviewed, administratively closed. Each step has a different owner and a different reason to stall. Make those steps columns on the board and use the words the department already uses, not the words from the handbook. A board that people have to translate into their own jargon won't be kept up to date.

The most important design choice comes next: split each step into a queue and an activity. So not just "review", but "waiting for review" and "under review". That may seem like hair-splitting, but it's the only way to measure waiting time. Without that split, an item that has sat untouched for three days looks exactly like an item someone is working on right now. With the split, you can say per step how much time went into the queue and how much into the work itself, and that ratio is almost always the answer to why the lead time is so long.

Each transition needs a short agreement about when work may move on: which fields must be filled in, which attachment is included, who has checked it. Two or three points per column is enough. That agreement prevents the ping-ponging everyone dislikes, where work moves a step forward, turns out to be incomplete and goes back. Sending work back is allowed, but it must be visible, because an item that has bounced back and forth three times is a signal about the intake, not about the person doing the work.

Swimlanes do the rest of the sorting. One lane per card type if the steps really differ, one lane per team if several groups use the board, and a separate lane for urgent work with its own rule: how much urgent work may run at once and who decides that. Urgency without a rule becomes urgency that is always there. Giving it its own lane and its own limit keeps it visible and countable, and afterwards you can show how much of the capacity it consumed.

Work also comes in types that do not follow the same path. A field service report, a customer request, an internal improvement task and a warranty case may share the first two steps and then diverge. You can then choose: one board where steps that don't apply are skipped, or linked boards per type with a shared intake. Both work, as long as the choice is deliberate and measurement stays separate per type. If your question lies mainly in that intake, with channels, feedback to the person reporting and agreements on response time, then a custom ticketing system is the better entry point, and you use the board behind it for handling the work.

Where a standard board starts to strain

Four situations occur on almost every shop floor and are poorly supported by generic boards. Work that moves back a step, because the timeline no longer adds up if the system only stores the latest status change. Work that splits into sub-items that travel through the process separately and must come back together at the end. Work that waits on someone outside your organisation, which has different consequences from waiting internally. And work with a hard deadline, where the remaining time belongs on the card and not in a separate overview.

In a standard tool these four are usually handled with labels, and labels can't be measured. You end up with a board that looks good and reporting that can't answer management's questions. The card itself deserves the same plain-speaking approach: it should show what the item is, who it's for, since when it has been in this column, whether it is blocked and which date has been promised. Use colour for the type of work, not priority, because priority changes and colour sticks. And when creating an item, require as few fields as you can bear, because every mandatory field is a reason for people to bypass the board.

What custom kanban software needs to do

These six components belong together. A board with neat columns but no limits becomes a long queue; limits without measurement are a matter of feeling; measurement without a link to the source system means someone keeps the board up to date alongside their real work.

Queue and work kept apart

A waiting column and a working column for each process step, so that stalling and processing are counted separately rather than lumped together in one status.

WIP limits with teeth

A limit per column, per lane or per person, with a defined response when it is exceeded: warn, block or ask for a reason.

Blockers as their own record

A blocker with a reason, the responsible party and a start time, so you can later cluster where work most often stalls.

Card age on the card

How long an item has been underway and how long it has been in this column, readable directly on the board rather than in a report afterwards.

Lead time in percentiles

A distribution rather than an average, so you can make a promise that is also kept in most cases.

Integration with the source system

The card reads from and writes to the system where the work item actually lives, with one owner per field and a recoverable synchronisation.

WIP limits and what they do to waiting time

A WIP limit is a maximum on the number of items allowed in a column at the same time. It sounds like a restriction, and it is the most effective lever you have on lead time. The reason is arithmetic rather than ideology. Little's Law states that the average lead time equals the average number of items in progress divided by the average throughput. If you halve the amount in progress while throughput stays the same, lead time halves. Nothing is made faster; the queue in front of it is simply shorter.

That clashes with what feels productive. Taking on a lot of work gives the sense that things are moving: everyone is busy, and every applicant has heard that their case is being handled. Meanwhile, fewer things actually get finished. Every switch costs the time of reading a file again, working out where things were left and explaining it to a colleague. On top of that, information goes stale: work that sits in the queue for a long time before anyone starts begins with details that no longer hold, and so it generates fresh questions.

You don't choose a limit at the drawing board. First measure how much is actually sitting in each column, set the limit slightly below that, and see what happens. Apply the limit to the columns where work is done, not to the queues in front of them, because capping a queue merely moves the problem to the intake. A limit per person works where work is truly personal, for example a specialism that only one person may perform; in every other case the column is the right place. And a good limit occasionally pinches. If it never stops anything, it is decoration.

More important than the number is what the system does once it pinches. You can warn, actually block, or ask for a reason. Blocking only works if there is an agreed way out: who may exceed the limit and where that is recorded. Asking for a reason is usually the richest option, because after a while those reasons become your improvement list. If the limit is breached four times in a row because the department is waiting on a single reviewer, you don't have a board problem but a capacity problem, and that is a conversation with figures rather than opinions.

Socially, a limit does something else too. It forces the team to finish before starting, and it makes the bottleneck visible without anyone having to point at it: the column that is full is the column that sets the pace. New work also gets a different answer. Not "we'll add it on top", but "then something else has to come off first, or it goes into the queue and the expected waiting time is this". For that, the software does need to show the intake queue and the expected waiting time, because saying no with a figure attached is a very different conversation from saying no on gut feeling.

One pitfall always arises: blocked work. An item waiting on a third party occupies a place within the limit. That is defensible, because it makes the pain visible, but it is equally defensible to move it to a separate waiting column so that the people doing the work can keep going. Make that choice explicit and let the measurement follow it, otherwise you will end up discussing numbers that nobody any longer understands. If your question is mainly about who is available when, with rosters, skills and capacity, then planning and scheduling software is what you need, alongside the board and not instead of it.

Limits on the columns where work is done, not on the queues
Measuring the starting position before choosing a number
Recording what the system does when a limit is exceeded
Keeping reasons for exceeding a limit as an improvement list
An explicit rule for blocked work within the limit
Fast-track lane with its own small maximum
Intake queue with expected waiting time for the requester

Lead time, cycle time and what the figures are worth

Measurement starts with two definitions that are often confused. Lead time is the time from the moment work arrives until it is delivered, as seen through the eyes of the requester. Cycle time is the time from the moment someone actually starts on it until it is done. The difference between the two is the queue at the front. Both figures are useful, but they answer different questions, and mixing them up is the most common reason a report is not believed internally. For each measure, record in which column the clock starts and in which column it stops, and put that definition in the report itself.

Don't work with averages after that. The distribution of lead times is skewed: many items move quickly, while a tail stretches far out, and it is that tail that determines how your team is judged. Plot each completed item as a point on a scatter chart with the completion date on the horizontal axis, and draw percentile lines through it. The 50th percentile is the coin toss. The 85th or 95th percentile is what you can promise. If the board asks how long something takes, the honest answer is a percentile together with the share of cases it covers, not a single figure that is wrong for half the cases.

Throughput is the second key number: how many items the team completes per period, broken down by type of work. Together with the amount of work in progress, it provides the check against Little's Law, and it makes questions about capacity answerable without time tracking. A cumulative flow diagram makes the trend visible: the vertical distance between the bands is the work in progress, the horizontal distance is the lead time, and a band that widens is a queue that is growing. That is an image that carries a board meeting without further explanation.

The most compelling number is usually flow efficiency: the time during which an item is actually being worked on, divided by the total lead time. In practice that share is small, and that insight shifts the conversation. As long as most of the time is spent waiting, working harder on the work itself achieves almost nothing, and shortening the queues achieves almost everything. Without that breakdown, the conclusion tends to settle on more people or more overtime, and that is precisely the conclusion you are trying to avoid with this board.

Whether any of this is possible depends on the data model. Don't store only the current status; record every status transition as an event with a timestamp, who made it, and from which column to which column. That way re-entries, pauses and retrospective corrections remain reconstructable, and you can recalculate a metric later without losing history. Also record when an item has been merged, split or withdrawn, because items that are silently deleted make your lead times artificially good. Retrospective corrections are fine, as long as the original event is preserved.

Finally, measurement changes behaviour, and that is a design question as well as a policy question. If the report is used to hold individuals to account, the board becomes fiction: cards get moved forward early, closed and reopened, and the figures look wonderful. So keep the metrics at process level, by type of work and by column, and say so explicitly. The card age on the board is the exception that may be visible at the individual level, because it is not an assessment but a tool: it tells the team which card needs attention today.

Making blockages visible rather than discussing them

A blockage should be a record of its own, not a label or a comment. It should capture the reason, the party that holds the next action, the time the blockage started, who is following it up, and what has already been tried. It sounds simple, and it is rarely done. Once that data exists, you can cluster the reasons, and it almost always turns out that a handful of causes account for the majority of the stoppages: an intake that arrives incomplete, a single person who must approve, a component that is out of stock, a system that only processes overnight. That list is worth more than a new board layout.

Distinguish here between waiting on a third party and waiting within your own organisation. For the requester, the clock keeps running in both cases, so report both figures: the full lead time and the lead time excluding the time the ball sat with the customer. Pick one as the figure you make commitments against and keep the other alongside it, because the debate over which of the two is fair is guaranteed to resurface. Finally, the daily stand-up deserves support: a view that reads from right to left and starts with the blocked and oldest work, rather than a round where everyone reports what they are working on.

Queue and processing split WIP limits Card age Cycle time Throughput by type of work Cumulative flow diagram Percentiles Blocker reasons Status events Flow efficiency

Connecting the board to the source system

The most common cause of a board's demise is duplicate administration. The order sits in the ERP, the report in the case system, the repair in the service package, and on top of that the board asks whether someone would also like to move a card. This works for a while, because everyone is enthusiastic at first. Then it quietly falls apart: the board falls behind, someone spots a discrepancy, and from that moment on the board is no longer trusted in meetings. Repairing it costs more effort than setting it up again is worth, so this is the question to resolve at the start, not at handover.

The workable rule is that every field has exactly one owner. The source system owns the content: the customer, the amount, the agreements, the attachments, the history. The board owns the flow: which column the item sits in, whether it is blocked, how long it has been there, which limit applies. The board shows fields from the source only as read-only, with a link through to the record itself. That way nobody has to wonder where to enter something, and that uncertainty is exactly where shadow administration in spreadsheets begins.

The status itself is the hardest part. Two patterns work. In the first, the source system remains the owner of the status and the board writes every move back, so the board is mainly a view; this is sensible if invoicing, feedback to the person reporting or a legal record depends on that status. In the second, the board owns the flow status and the source system receives only the moments it genuinely needs, for example accepted and completed. Choose one. A status with two owners produces conflicts that nobody can explain afterwards.

Technically, that breaks down into a few choices you are better off making in advance. Link records with a fixed external key, so you never have to match on name or description. Use events or webhooks for speed, and alongside them a periodic reconciliation run that compares source and board, because messages do get lost, and you want the difference detected automatically rather than reported by a user. Make write actions idempotent, so a repeated message doesn't move a card twice. Place outgoing messages in a queue, so an outage at the source causes delay rather than loss. And keep a log of inbound and outbound traffic with its content, because the discussion about why the board shows something different can only be settled with that log.

Permissions must come along too. On a board showing records, visibility per lane and per card should follow the same rules as in the source system, and that applies doubly to a display on a large screen in a corridor or workshop. There, a card should show an order number and a process step, not names or health data. Then the shop floor itself: touch operation with large areas, a board readable from a distance, scanning an order or part number instead of typing, and staying usable without a connection. This is often the direct reason custom software comes into view. A generic tool works fine on a laptop, but not with gloves on.

One thing from practice is worth mentioning about rollout: start by taking over the process as it really runs today, even if everyone agrees it should work differently. A board that shows the desired process will not be kept up to date, because the cards do not match what people actually do that day. Begin with one team, record a baseline of work in progress and lead time, and only then change columns and limits. That way you have a comparison and not just a feeling. Close off an improvement with a change to the board itself, so the new agreement is visible in the tool rather than in a report nobody reads back.

When an off-the-shelf tool is the better choice

There are good generic kanban boards, and many organisations already have licences for them through a package they use anyway. If your work fits a generic board, columns with limits and a cycle time report are enough, and users already have an account, you buy that and set it up without a development project. We would rather tell you that now than halfway through a quote process. Custom software does not pay for itself in a situation that can be solved with a setting in an existing package.

Custom development pays off in a limited number of situations. When the board needs to be part of an application the shop floor already uses, for people who will not get a second login. When rules apply to column transitions that the system must enforce rather than merely advise on. When your metric definitions are genuinely your own, for example a deadline from a contract or a waiting time with a client that must be tracked separately. When items are created automatically from a source system in volumes nobody can track by hand. And when the data on the cards does not belong in an external service.

Often the middle path is the answer: an existing package for the teams already working with it, and custom development for the shop-floor view and the reporting layered on top of the events from that package. The downside of building it yourself is also real: you maintain it, and you remain responsible for explaining and keeping the metric definitions current. If you want to start small with a web application around a single process, a workflow web app is the lighter route, with the same question about who owns which fields.

One owner per field: source or board
Storing status transitions as events
Webhooks for speed, reconciliation for accuracy
Idempotent writes and an outbound queue
Conflicts go to a person, not resolved silently
Carrying over permissions from the source system
Wall display without personal data
Touch controls and scanning on the shop floor

Frequently asked questions about kanban software

A plan starts from an end date and spreads the work across time and people. A board starts from the flow: what is in progress, what is waiting, what is done. For ongoing work that arrives continuously, a plan is cumbersome and quickly outdated, whereas a board with limits and a lead time measurement stays useful. If you are managing a single project with phases, milestones and a budget, project management software is the right place, and the board is at most a supplement for execution.

First, check how many items are currently in progress per column, set the limit slightly below that number and see what happens. Apply the limit to the columns where work is actually done, not to the queues in front of them. Also agree what the system does when a limit is exceeded: warn, block, or ask for a reason. Those reasons become your improvement list after a while. A limit that never bites is decoration, and a limit that is breached every day is set too low or the bottleneck sits elsewhere.

Lead time runs from intake to delivery, as the requester experiences it. Cycle time runs from the moment someone actually starts on the item until it is done. The difference between the two is the queue at the front. Report them side by side, with for each measure the column where the clock starts and stops, and use percentiles rather than averages. The distribution is skewed, so an average promises something that is not met in a considerable share of cases.

No, and that is exactly what kills a board. A workable setup has one owner per field: the source system owns the content, the board owns the flow. The card shows the source data for reading and links through to the record itself. For status, choose a single owner as well, either writing back to the source or only the moments the source needs. That calls for events for speed, a periodic reconciliation run for accuracy, and a log of all traffic.

That is where it works best. Requests, reports, orders, repairs, inspections and case files are discrete items with a start and an end, which is exactly the kind of work a board organises. The columns then follow the department's handling process rather than project phases. If the work splits into types with different steps, those types get their own lanes or their own boards with a shared intake, so that measurement stays separate per type.

If your work fits a generic board, columns with limits and a cycle time report are sufficient, and users already have accounts, an existing package is the most sensible choice. Custom development pays off when the board needs to live inside an application the shop floor already uses, when rules must be enforced at a column transition, when your measurement definitions are truly your own, when items are created automatically from a source system, or when the data on the cards should not sit with an external service.

Related services

Custom project management software

If the need is to steer a single project, with phasing, planning, hours and budget rather than flow on the shop floor, you want custom project management software.

Custom BPM platform

If a process with forms, decision rules and strict routing must be enforced rather than made visible on a board, a custom BPM platform is the better foundation.

Building a custom ticketing system

If your question lies mainly in the intake, with channels, feedback to the person reporting and agreements on response time, start with a custom ticketing system and use the board behind it.

Planning and scheduling software

If the core question is who is available when, with rosters, skills and staffing across shifts, planning and scheduling software belongs alongside it.

Put your own process on a board

Tell us which steps the work goes through in your organisation, where it usually gets stuck, and which system currently holds the truth. Those three answers almost always show whether you can configure an existing package, or whether the integration and measurement definitions require custom development.

Book an advisory call info@appfront.nl