Practical PlaybookATLASSIAN

The Jira WIP Limit Turned Red. What Is the Team Allowed to Do About It?

Author
Alex Florian
Published
Updated
Reading time
4 min

Seven cards sit in a review column intended to hold no more than four unfinished items. Jira shows the warning. Someone starts another piece of work anyway.

It's easy to call that poor discipline until you ask what the person was expected to do instead. Perhaps their assigned task must start today, the missing reviewer belongs to another team, and nobody present can delay new work or obtain the review. The board is asking for one behavior while management rewards another.

A work-in-progress limit, or WIP limit, is a threshold for unfinished work in a defined part of the process. Jira's visual constraint can highlight a breach without technically preventing another card from entering the column. The team's response has to exist beyond the indicator. [1][2]

The eighth card makes the trade-off visible

Continue the hypothetical scene. A developer has finished preparing an eighth item for review and is about to start a ninth. The review queue contains a small change that another qualified colleague could examine and a more difficult item waiting for a specialist outside the team.

“Respect the limit” doesn't tell them which of those constraints they can affect. A useful discussion might lead the colleague to review the small change while the delivery lead obtains a decision on the specialist work. The developer's next start may be delayed to help an existing item finish, but that delay has to be acceptable to the people relying on the original plan.

This is where I would focus before adjusting the threshold. Can the team redirect attention toward finishing, and can it reach someone who controls the dependency it cannot resolve locally? If the answer is no, a louder warning will mainly make the contradiction more visible.

The limit is useful when it changes what the team can do, not just what it can see. It may expose a staffing problem, an approval bottleneck, or a work-allocation rule that keeps sending more items into the same queue.

Four is a starting hypothesis, not a sacred number

The original limit may reflect available reviewers, typical item size, or a belief that too much simultaneous work is increasing waiting. Those are reasons to examine it. There is no need to pretend the first number was perfect.

Raising four to seven immediately, however, removes the warning without testing any explanation of the congestion. A revised threshold becomes more convincing when the team can explain why the work or capacity supports it—not merely why the old number has become uncomfortable.

The count needs a stable meaning too. A blocked review is still unfinished review work when that is what the limit covers. Moving it outside the visible queue to improve the number would make the constraint harder to understand, not easier to manage.

An exception can be a decision rather than a loophole

There may be a good reason to exceed the limit. In an illustrative variation, an urgent repair needs review to restore a materially affected service. Waiting behind routine changes may create more harm than a temporary breach.

The team can accept that exception while being clear about the work it displaces and how it will return to the normal policy. Treating every breach as failure would discourage useful judgment. Treating every request as an exception would leave no policy to apply.

What matters afterward is whether work actually finishes more predictably. A healthier column accompanied by an informal queue elsewhere hasn't improved the service. Looking at the age of unfinished items, completed work, and quality gives context without turning every observation into another target.

For the eighth card, the question is immediate: will someone help complete the reviews already waiting, obtain the missing specialist decision, or explicitly accept the additional work for a stronger reason? That conversation turns the warning into a management choice. When everyone has to continue exactly as before, the team doesn't need another reminder to notice red. It needs a workable response to what red revealed.