[feature]: Kanban lane WIP limit
Is there an existing issue for this?
- [X] I have searched the existing issues
Summary
A standard feature for Kanban workflow is to have WIP (work-in-progress) limits based on specific board lanes. This feature would implement such setting, to be able to set it on a per lane basis, and once that limit is hit, it should not be possible to drag any more ticket to that lane/status.
Why should this be worked on?
WIP limits is a very foundational part of the Kanban workflow which focus on getting tickets fast through lanes and avoid them getting stuck in certain places. This should be pretty easy and simple to implement and provide a lot of value for any team that works according to the Kanban workflow.
if you assign, I can try that.
@vihar @pushya22 Could you please assign this issue to elnfar? Thanks!
@tvarsis, thanks for detailing the feature request, and @elnfar, thanks for your interest in contributing to this issue. However, since this feature requires in-depth product knowledge and integrates with our layouts, it’s a bit complicated to cover all edge cases. For example, we need to ensure all layouts are consistent—if we implement a lane limit for Kanban, how does it affect our list or spreadsheet view? Additionally, we need to handle different alerts when limits are exceeded and allow toggling lane limits on and off from project settings.
Therefore, we have decided to handle this issue internally. We’ll come up with a timeline for when this feature can be shipped shortly.
@tvarsis, thanks for detailing the feature request, and @elnfar, thanks for your interest in contributing to this issue. However, since this feature requires in-depth product knowledge and integrates with our layouts, it’s a bit complicated to cover all edge cases. For example, we need to ensure all layouts are consistent—if we implement a lane limit for Kanban, how does it affect our list or spreadsheet view? Additionally, we need to handle different alerts when limits are exceeded and allow toggling lane limits on and off from project settings.
Therefore, we have decided to handle this issue internally. We’ll come up with a timeline for when this feature can be shipped shortly.
Thank you for the information, I do like the what u do and have built the same kinda internal project for the company im working for, feel free to let me know if you need a feat, or you can simply assign me.
thank you.
Just noting my desire for this issue.
It would also be great if we could do the limits based on other things, such as by user. i.e. I may not want a global Lane limit, but instead a user limit where you can only have 5 Issues open for a given assignee in that Lane.
Just noting my desire for this issue.
It would also be great if we could do the limits based on other things, such as by user. i.e. there's no global Lane limit, but you could set it so that you can only have 5 Issues open for a given assignee in that Lane.
@vihar any news on this?
Excited for this feature!
As per Little's Law, if there is going to be multiple limits, such as per lane or per column, in aggregate they need to equal the flow/board's WIP limit and the aggregated limit is the one used to compute cycle time and to balance with throughput. The use would be for the team to set the board WIP Limit and then allocate that limit to sub WIP stages, but I think these allocated sub WIP limits absolutely should be soft limits. Only the board's WIP limit should have the option of being a hard limit.
A per user WIP limit could be quite interesting and helpful for users that have multiple parallel project workflows, but it would not be used in the process flow analysis such as cycle time, this would be an "off-board" limit.