How would you pick a team's first work-in-progress limits and adjust them over time?

## Start from the board you already have The most reliable first limit is descriptive rather than prescriptive. Count how many cards each column actually holds on an ordinary day, then set the cap at that number or one below it. This works because it is immediately credible - nobody can argue that the team is being asked to do something it has never done - and because it starts the number where it will bind occasionally rather than never. The alternative approaches both fail in predictable ways. A cap copied from another team encodes that team's skill mix, column design and dependencies, none of which transfer. A cap derived from an ambition - what the team wishes it were doing - gets breached in week one and quietly abandoned in week two. ## Heuristics are starting points, not answers Common starting heuristics include roughly one card per person working at a stage, or slightly fewer to force pairing and helping. They are worth knowing and worth arguing with: - They assume everyone at a stage can work on anything at it, which is rarely true where a qualification or an access right is involved. - They ignore how long items sit waiting versus being worked, so a stage whose cards mostly wait needs a very different number from one whose cards are mostly being touched. - They treat columns as equivalent, when a column that covers two distinct kinds of work behaves like two columns sharing a number. Treat any heuristic as an opening bid whose only job is to get a number onto the board so the team can start learning from it. ## Tightening: a cap that never binds teaches nothing The single most useful diagnostic is whether the limit ever refuses a card. If a column has not reached its cap in months, it is not constraining anything - it is a decoration that lets the team say it has limits. Tighten it by one and watch. Repeat until the column occasionally blocks and the team occasionally has to decide what to do about it. That occasional block is the entire product of the mechanism. It is where the conversation about the constraint gets started, where helping behaviour comes from, and where the pressure to fix a structural problem originates. A board that never blocks generates none of it. ## When the number is not the problem The opposite symptom - a column that blocks constantly - needs a diagnosis rather than an adjustment. | Symptom | Likely cause | The move | | --- | --- | --- | | Cap never reached in months | number set too loose | tighten by one and observe | | Blocks occasionally, swarming clears it | working as intended | change nothing | | Blocks weekly, swarming never clears it | structural: skills, approval, dependency | change the structure, not the number | | Breached quietly and often | the rule is not being treated as a rule | rebuild the agreement before touching arithmetic | | One column behaves like two | the column covers two kinds of work | split the column, then cap each part | The third row is the one that separates a lead from a practitioner. If a column blocks every week and no amount of helping clears it, the number is not too low - the stage genuinely cannot go faster with the people and permissions it has. Raising the cap makes the blocking stop and the delay continue, which is strictly worse, because the delay is now invisible again. The real options are cross-training a second person into the constrained skill, getting an approval delegated, reducing the demand entering the board, or accepting the rate and planning around it honestly. ## Exceptions, and how they dissolve a limit Urgent items that bypass the caps are the most common way a working system decays. If exceptions are going to exist, agree in advance how many may be in flight at once - usually one - and count them on the board rather than beside it. Two or three concurrent urgent items do not stress the constraint; they replace it, and the board reverts to a picture of everything that has been started. ## The argument you have to win Tighter limits produce visible waiting, and visible waiting is politically expensive. Somebody outside the team will see a person with nothing to start and read it as waste. The lead's job is to hold the line with the trade stated plainly: the team is optimising for finished work rather than occupied people, and the waiting is the price of items that actually complete. That argument is hardest exactly when it matters most. A 7-person team facing a regulator's audit date 23 working days out will be asked to raise every cap so that everything can be started at once. The honest answer is the reverse: under a fixed date, tighter limits and ruthless finishing produce 8 completed items rather than 14 items at 70%, and the one structural move worth making - a second qualified reviewer, a delegated sign-off - should start today rather than in the final week. ## Cadence of change Change one number at a time, never in the middle of a block, and give each change several weeks before judging it. Adjusting two columns at once, or adjusting weekly, makes it impossible to attribute any change in outcome to anything.