Work in progress

Started does not mean actively being edited

A pull request waiting for approval is still unfinished. So is a feature whose implementation has paused while the team waits for a product decision. Counting only items receiving attention today understates the amount of work already committed to the workflow.

The start and finish points should be explicit. Some teams count a ticket as started when it enters development. Others track a narrower queue, such as requests awaiting review. Both views can help, provided they are not presented as the same measurement.

What a WIP limit changes

Consider an illustrative team with six unfinished features. A developer finishes their current implementation and sees that three other features are waiting for review. Starting a seventh feature adds activity, but helping review an existing one may get useful work to users sooner.

A work-in-progress limit makes that choice visible. It creates a reason to finish, unblock, or reconsider existing work before pulling in something new. It does not imply that every engineer must remain busy on the same task.

Diagnose the queue before changing the limit

A low limit cannot fix an unavailable external reviewer. It can reveal the dependency earlier by preventing more work from accumulating behind it.

Inspect the age, class, and blocking reason of unfinished items. Pair the count with cycle time and completed work. A smaller queue is useful when it improves flow, not merely when items are moved to a different status to keep the board looking tidy.