The project starts, the tasks are distributed and your team is motivated - it does not get better than that. But whoever is not careful now and works on too many tasks in parallel will run into problems by the end of the sprint. From experience we know that every employee is already sufficiently busy with more than 2 tasks at the same time. More issues only create a focus problem - and that is exactly what WIP limits are for.
What a WIP limit does
WIP stands for work in progress, meaning work that has been started. A WIP limit defines how many issues should be in a status column at the same time. If “In Progress” has a limit of 5 and holds 8 issues, that is a visible signal: before anyone starts something new, what has been started should be finished first.
A simple number in the column header, but it changes how a team works.
Why working in parallel is slower
Five issues at once feel like more output than one after another. In everyday project work it is the other way round.
Every switch costs time: You read yourself back in, reconstruct the current state, remember why you solved something a particular way. With five open issues you do this all day long.
On top of that comes something you see in every issue list: An issue that is 90 percent done is worth as much to your customer as one that has not been started at all - namely nothing. What gets paid for is completion, not progress.
This is exactly where the WIP limit comes in.
Where the limit sits on the Taskboard
On the Taskboard of the Reporting Plugin you set the limit per status column. The column header then shows the workload as “number / limit”, for example 5 / 3. If the limit is exceeded, the number appears in bold red, and hovering over it shows an explanatory text.
There are two ways to set a limit. Both only work with saved queries and only if you are allowed to edit the query:
- In the query form: When editing the query you find a field per status column in the Options section. Enter the desired number there, empty means no limit.
- Directly on the board: Hover over a column header and click the limit. Enter a number, press Enter, done. Escape cancels.
Because the limit belongs to the saved query, every board can have its own limits. So the board of your support team works with different boundaries than the one of your development team, without the two getting in each other’s way.
There are three things you should know about this:
- The limit does not block anything. You can still drag an issue into a full column, the column is then simply marked. This is intentional: a limit should start a conversation, not prevent work.
- The limit applies to the entire column, so across all swimlanes.
- A limit of 0 means “this column should stay empty”. As soon as an issue sits in it, the column is marked. Practical for columns where nothing may be left lying around.
Which number is the right one?
This is the question that always comes up first. A good starting value:
Number of people in that column plus one.
So five for four developers. That roughly matches the two tasks per person most people handle well, and leaves room for the case where someone gets stuck and has to start something else.
What matters is not the starting value, but what happens afterwards. Watch the board for a few weeks: If the limit is broken constantly and nobody cares, it is too low or is not taken seriously. If it is never reached, you can save yourself the trouble.
Which columns benefit from a limit:
- In Progress - this is where one almost always belongs, the classic case
- Review - often the actual bottleneck, because reviewing is unpopular and gets left behind
- Backlog - a limit usually makes no sense here, this is where work is deliberately collected
- Waiting for customer - a special case: the limit shows you how much work is currently hanging outside your control
What happens when the limit kicks in
As soon as the column turns red, a decision is due. That is what the number is there for.
The right reaction is rarely “raise the limit”. Usually the question is: Why are the issues in this column not moving forward? From practice we mainly know three reasons:
- An issue has been waiting for feedback for days that nobody is chasing up
- Two issues are actually blocked, but nobody has made that visible
- The column before it pushes work forward faster than this column can process it
In all three cases a higher limit does not help. It would only make the problem invisible again.
In practice two functions of the board complement each other here: The red lock on a card shows that an issue is blocked by another, still-open issue. Together with an exceeded limit you therefore see not only that something is stuck, but also what on.
The limit has to be backed by the team
WIP limits only work if the team stands behind them. A number set by project management alone and ignored by everyone is just a red digit in the column header.
So set the first limit together, not alone at your desk. And clarify beforehand what happens when it is exceeded - even if it is only that you briefly go through the column in the next daily.
How to get started
- Open your issue list and switch to Board under Options at Display results as
- Save the view as a custom query, ideally shared with your team
- Set a limit on the “In Progress” column: number of people plus one
- Watch it for two to three weeks and address the limit in your team when it turns red
- Adjust the number once you have gathered enough experience
That is all it takes to start. You can add all further columns later.
All information about our extensions for Redmine can be found on the product page. The Reporting Plugin is subject to a fee and is available separately or as part of our Business-Class Bundle as well as the Enterprise+ Bundle. The function described here can be tested extensively in our online demo.