Work in progress limits for Kanban boards. Give each column a minimum and a maximum, and the board header shows the live count against the maximum, colouring an over-full column red and an under-filled one amber. Enforcement is chosen per workflow: soft warns and allows the move, hard refuses a move that would push the column past its maximum. Counting is per project, so a full column in one project never blocks another.
- Installs
- Available
- Support
- Vendor Supported
- Trust
- Self-Hosted
Active deployments
Priority response
Your infra, your data
Screenshots
Key Features
Minimum and Maximum Per Column
Every board column carries its own minimum and maximum. Zero means no limit, so you can constrain the columns that matter and leave the rest alone.
Live Count in the Header
The column header shows the current count against the maximum, so the state of the board is visible without opening a report.
Colour on Breach
A column over its maximum renders red and a column under its minimum renders amber, which makes a starved column as visible as an overloaded one.
Soft Enforcement
The default. The board highlights the breach and the move still goes through, which is usually the right starting point while a team learns its real capacity.
Hard Enforcement
A move that would push the target column past its maximum is refused, with a message naming the column, the count, and the limit.
Chosen Per Workflow
Soft or hard is a property of the workflow, so a team ready for hard limits can have them while another team on a different workflow is not forced into it.
Counted Per Project
The count is scoped to the project, so a full column in one project never blocks a move in another even when both use the same workflow.
Active Work Only
The count includes active task rows sitting in the column, so archived items do not inflate a column and make a team look busier than it is.
Minimum Never Blocks
The minimum is advisory. It colours the column and starts a conversation about a starved stage, but it never refuses a move.
One Rule, Every Path
The same decision runs behind a Kanban drag and behind a status change on the task form, so a limit cannot be walked around by using a different screen.
Exact, Documented Rule
A move blocks only when enforcement is hard, the target column has a maximum above zero, and the count after the move would exceed it. Everything else is allowed.
Clean to Disable
Turn the add-on off and enforcement stops immediately. The limit columns stay in the schema and the numbers you set are still there when you turn it back on.
No New Board Object
A board column is a status and a board is a workflow, so limits attach to the objects you already configure rather than introducing another layer to keep in step.
Bottlenecks Made Visible
Because the count is on the header of every column, the stage that is actually holding the team up stops being a matter of opinion.
About this plugin
Why WIP Limits for Orangescrum?
A Kanban board without limits is a list with columns. Everything gets started, very little gets finished, and the stage that is holding the team up is a matter of opinion. Limits make the constraint visible and, when you are ready, enforceable.
Minimum as well as maximum
Each column carries a minimum and a maximum, and zero means no limit. The maximum catches the familiar problem of too much in flight. The minimum catches the quieter one of a stage nobody is feeding, which usually means the person who works that stage has nothing to do while the team wonders why nothing is coming out the end.
Warn first, block later
Enforcement is set per workflow. Soft is the default: the board highlights the breach and the move goes through anyway. That is usually the right place to start, because a team needs a few weeks of honest numbers before it knows what its real limit is. Switch that workflow to hard when the team is ready, and a move that would push a column past its maximum is refused with the column name, the count, and the limit.
Counted where it makes sense
The count is per project. Two projects sharing a workflow do not share a limit, so a busy team never blocks a quiet one by accident. Only active task rows in the column are counted, which keeps archived work out of the number.
The rule, exactly
A move is blocked only when three things are true at once: the workflow's enforcement mode is hard, the target column has a maximum above zero, and the count in that column after the move would exceed the maximum. Anything else is allowed. The minimum never blocks anything, which matches the way most teams already expect Kanban limits to behave.
Built into the boards you already use
There is no separate board object to maintain. A column is a status and a board is a workflow, so limits attach to the configuration you already have and the Kanban board reads them directly. There is a wider overview of Kanban working in Orangescrum at /kanban-board.
What's included
- Minimum WIP and maximum WIP per board column, with zero meaning no limit
- Live count against the maximum in the Kanban column header
- Red highlight over the maximum and amber highlight under the minimum
- Soft or hard enforcement selected per workflow
- Soft mode highlights the breach and allows the move
- Hard mode refuses a move that would exceed the maximum
- Refusal message naming the column, the resulting count, and the limit
- Counting scoped per project so shared workflows stay independent
- Counting limited to active task rows in the column
- Enforcement on the Kanban drag path and the task form save path
- Advisory minimum that never blocks a move
- Editor fields on the status setting and workflow screens
- Clean disable that stops enforcement without dropping the configured limits
- Multi-tenant company-scoped data isolation
Compatibility
Requires the Orangescrum Self-Hosted edition running PHP 8.2+, CakePHP 4.6+, and PostgreSQL 16. The plugin folder is WipLimit and it is gated by the WIP_LIMIT_ENABLED flag in config/constants.php. Hard mode blocking runs inside the Status Workflow transition pipeline, so the Status Workflow add-on has to be installed and enabled for a move to be refused. Without it the limit columns and the board highlight still work and only the block is skipped. The migration is idempotent, so it is safe on installs where those columns already exist. Multi-tenant aware, so every limit and count is company-scoped.
Installation
A self-hosted install takes a few minutes. Buy the add-on, drop the plugin into your plugins/ directory, run the migrations, and you're live.
- 1
Buy the add-on
Purchase the WIP Limits add-on from /self-hosted/pricing at $499/year per company, payable annually.
- 2
Drop the plugin into your install
Copy the WipLimit/ folder into plugins/ on your self-hosted Orangescrum server.
- 3
Enable the feature flag and register the plugin
Add `define('WIP_LIMIT_ENABLED', true);` to config/constants.php and register `WipLimit` in src/Application.php with `routes => true, bootstrap => true`. Keep STATUS_FLOW_ENABLED on so hard mode blocking can fire.
- 4
Run the database migration
Run `bin/cake migrations migrate -p WipLimit` to add the limit columns. The migration is guarded, so it is safe on installs where the columns already exist.
- 5
Choose enforcement for a workflow
Open Workflow Settings, pick a workflow, and set WIP limit enforcement to soft or hard. Soft is the sensible starting point.
- 6
Set limits on the columns that matter
Edit each status in that workflow and set its minimum and maximum. Leave a column at zero to keep it unlimited.
- 7
Open the board and watch the counts
Open a project using that workflow. Every column header now shows its count against its maximum, over the maximum in red and under the minimum in amber.
Frequently Asked Questions
Does the minimum limit ever block a move?
▾
No. The minimum is advisory. It colours the column amber so a starved stage is visible, but it never refuses anything. Only the maximum can block, and only in hard mode.
What is the difference between soft and hard?
▾
Soft is the default: the board highlights a full column and the move still goes through. Hard refuses a move that would push the target column past its maximum, and the message names the column, the resulting count, and the limit. The choice is made per workflow, not per company.
Do two projects on the same workflow share a limit?
▾
No. Counting is per project. A full column in one project never blocks a move in another, even when both projects use the same workflow and therefore the same limits.
Does this work without the Status Workflow add-on?
▾
Partly. The limits, the header count, and the board colouring all work on their own. The hard mode block runs inside the Status Workflow transition pipeline, so without that add-on installed and enabled nothing is actually refused.
Can somebody get around a hard limit by using a different screen?
▾
No. The same decision runs behind the Kanban drag handler and behind a status change on the task form, so both paths reach the same verdict.
What happens to our limits if we switch the add-on off?
▾
Enforcement stops immediately and the board stops highlighting breaches. The limit values stay in the schema, so switching it back on restores the numbers you had set rather than making you enter them again.
Ready to deploy WIP Limits on your own infrastructure?
Talk to our team about Orangescrum Self-Hosted Enterprise: your data, your servers, full control.