Nobody decides to have ten tickets in progress. It happens one at a time: a quick fix here, a review request there, a "can you just take this while you wait". By Friday one person is holding ten things, and the board looks fine.

This is about why it happens, what Jira can show you, and where the built-in tools stop.

Why it happens

  • Starting is free. Moving a card to In Progress costs a click, and finishing costs days.
  • Blocked work stays "in progress". Waiting on a reply, a deploy or a review, people start something else, and the first item never leaves the column.
  • The helpful people collect the most. Whoever says yes fastest ends up with the pile.
  • Nobody sees it. A board shows cards, not how many one person holds.

Column limits count the column, not the person

Jira's column constraints set a minimum and maximum number of work items per column and colour the header when it is exceeded. They count every work item in the column, whoever holds it, and people can still move work in. A column limit of 6 is respected with a split of 4, 1 and 1. Someone working across three boards can be under every column limit and still hold ten items.

Spot it with JQL

This finds work that is in progress and assigned:

statusCategory = "In Progress" AND assignee is not EMPTY ORDER BY assignee

Save it as a filter and add a Two dimensional filter statistics gadget with Assignee on one axis. Each row is one person's count across every project the filter covers. To check one person, use assignee = currentUser() AND statusCategory = "In Progress".

Assignee swimlanes on the board give a similar view for one board.

It shows the problem and stops nothing. It works when the team looks at it every day.

Automation, after the fact

A rule can trigger on a work item transitioning to your In Progress statuses, look up work items with assignee = {{issue.assignee.accountId}} AND statusCategory = "In Progress", compare {{lookupIssues.size}} with your limit, and comment or notify a lead.

The catch is timing. The rule runs after the move, so the work has already started, notifications go out, and two moves at the same moment can both slip under the count. It is a nudge. Each run also counts towards your Automation usage.

Workflow conditions and validators

To stop the move itself, the check has to run on the transition. Jira's built-in conditions and validators can look at the work item being moved: its fields, the user's permissions, sub-task status. They cannot count how many other work items the assignee already has in progress. That needs a scripted validator or an app.

Before you pick either, decide four things: across all projects or per project, what counts as starting work (To Do into In Progress yes, In Progress into In Review no), who is exempt (on-call, support), and what happens if the check cannot run. A limit that blocks people when Jira is slow does more harm than good, so let the move go ahead.

Or agree it as a team first

Pick a number, say 3, and decide what happens at the limit. In Kanban the answer is usually to help finish something instead of starting something. That alone fixes a lot. We wrote the longer version, including the flow theory, in a guide on Kanban WIP limits per person: https://kayabyte.dev/atlassian/guides/kanban-wip-limit-per-person-jira

An app that puts the check on the transition

Full disclosure: we build Personal WIP Limits, so weigh this with that in mind. Personal WIP Limits for Jira adds a workflow rule, "Personal WIP limit", that you put on the transitions that start work, in company-managed and team-managed workflows.

  • When the assignee is at their limit, Jira shows a message and the work item stays where it is.
  • One limit for everyone, counted across all projects or per project. Projects can have their own limit or be switched off, and groups can be exempt.
  • Moves between In Progress statuses and unassigned work are never blocked. If the app cannot check, the move goes ahead.
  • An admin overview shows work in progress per person against the limit.
  • It stores only its settings and makes no calls outside Atlassian.

Limits are a guardrail, not a guarantee, and everyone gets the same limit in this version.

If you only want visibility, the dashboard is enough. If you want the move itself to stop, the check has to sit on the transition.

I covered the column, filter and Automation options step by step in an earlier post: https://dev.to/kayabyte/how-to-set-a-wip-limit-per-person-in-jira-and-what-the-built-in-options-miss-52k5

Jira and Atlassian are trademarks of Atlassian. Kayabyte is independent and not affiliated with or endorsed by Atlassian.