WIP limits, explained for managers

Capping work in progress sounds like slowing down. In practice it's the fastest way to get things finished. Here's how to pick the number.

A work-in-progress limit is a cap on how many tasks can sit in a column at once. When the In progress column is full, nobody starts something new until something moves out. It's one of the oldest ideas in kanban and one of the least used.

Why it works. Every task in progress costs attention. People switch between five half-finished things, each switch costs time, and nothing reaches Done until late in the week. A limit forces the team to finish before starting, which shortens the time each task spends in progress. Shorter cycle times make dates more predictable, which is what managers usually want in the first place.

How to pick the number. Start with the number of people on the team and add one. A team of four starts at five. Watch it for two weeks. If people are regularly idle waiting for a slot, raise it by one. If the column is always full and tasks sit for days, lower it.

What to do when the column is full. This is the part that matters. Instead of starting new work, help finish what's there: review a pull request, pair on a blocked task, clear a question for someone. The limit turns "I'm done with my task" into "what can I help finish?"

Limits on review, too. The column that usually overflows is In review. Put a limit there and reviews stop piling up at the end of the sprint.

In TaskD you set a limit per column on the board. The column header shows 3 / 5, and the board won't let anyone pull a sixth card until one moves on. The limit is a team agreement, not a lock — an admin can override it, and the override shows up in the activity log.

Managers often worry that limits make the team look less busy. They do, briefly. Then the finished column starts filling faster than it used to.