In a Slack conversation recently, someone asked “Isn’t it a big assumption that breaching WIP is always bad?” It’s a great question, and the answer is more interesting than it first looks.
Let’s start with the obvious case. A WIP limit is part of a policy that the team agreed to. The policy says what the team will do, and here it says the WIP in a column will not exceed a certain value. So if the WIP goes over that value, then yes, that’s bad. We agreed to a policy and then didn’t follow it. Simple.
Except that original question was asked in the context of working in Jira, and that shifts the focus.
What Jira actually measures
Jira only supports column-based WIP limits. That means what Jira enforces might not capture the subtleties of what your policy actually says.
Imagine your policy reads: the WIP limit for this column is 5, unless an item in the column is expedited, in which case the limit rises to 6. That’s a perfectly reasonable policy, and Jira can’t express it. All Jira knows is the number 5. So the moment that expedited sixth item appears, Jira flags you as over the limit, even though you’re following your policy exactly.
In a case like that, the fact that Jira thinks you’re over doesn’t mean you violated anything.
So is breaching WIP bad?
It depends on what the breach actually represents.
If your WIP measurement accurately reflects the policy you agreed to, then yes, breaching it is bad. You said you’d work one way and then you didn’t.
If your WIP measurement is wrong because your tooling can’t express the policy, then the breach is an artifact of the tool, not a failure of the team.
The lesson isn’t that WIP limits don’t matter. It’s that the number on the board and the policy in your head aren’t always the same thing. Before you treat a breach as a problem, check which one you’re actually looking at.
If you’d like help making better decisions from your team’s metrics then let’s talk. I’m available to help.