Can we set WIP limits by issue type

[Felipe_Di_Gregorio__Globant_]

In our kanban board we track development tasks, hypothesis, experiments and kaizen items. Not all of them require constant work from the team, some are ongoing items and if we count them in the WIP limit it messes up our actual capacity. Is there a way to set a filter to only count certain issue types for the column's WIP limit?

[Matthias Michel]

Actually, I don't realy understand the reason why you can exclude sub-tasks from a WIP limit. That doesn't really make sense... Pretty basic is to have stories including their sub-tasks on a kanban board. Not what really matters in terms of WIP is the actual number of sub-tasks being in progress. But with the behavior of Jira Software, every sub-task is resulting in a count of 2 issue being in progress. What yes, is somehow true, but what do you take from it? I don't know.

So from my perspective, Jira should offer to define WIP limits per issue type. This would also come handy thinking of also dealing with bug tickets in the same board. Like this you could help the team to not fully focuse on bugs or stories but to maintain a healthy balance.

@[deleted]: please plan for such a feature in one of the next releases as in its current way of implementation the value add is quite limited.

[sebastian]

I'd very much appreciate such a feature too. The Board Settings allows to exclude Sub-Tasks, but one can not specify more issue types to ignore and/or set WIP limits for.

In my team we display Epics at the top of our board to be confronted with the Number-of-Epics in progress everyday in the standup.

The idea is that we want to limit the number of Epics In-Progress AND the number of Stories/etc and define limits for each of them. At the moment we only can limit the sum of all of them

So there is a point of to have WIP limits by issue type @Nic Brough -Adaptavist- 

[Nic Brough -Adaptavist-]

Not really, Epics aren't really things you would put on a board, as they're not actionable items themselves (and their in-progress status is not something you set, it's determined by the status of the issues they contain - an Epic is in-progress by virtue of having one or more of its stories in-progress)

[sebastian]

For us Epics are very much actionable items: we ask ourselves "what do we need to do to finish out this Epic" everyday ""what do we need to do to finish out each Story in progress".

And yes an Epic is In-Progress when at least one of it's Stories is In-Progress, and it's Done when all it's Stories are done.

[Nic Brough -Adaptavist-]

Ok, so you're not using Epics the way they are built for.  That's fine, but you can't expect a tool that handles them as intended to work properly with it.

The answer to "what do we need to do to finish out this Epic" is supposed to be the same every time you ask - "deal with the stories inside it".  

[Nic Brough -Adaptavist-]

No, a column needs to count all issues in it towards the wip limit.  Otherwise there's no point having one.

[Lasse Rørbæk Nielsen]

I would almost always agree with this statement, however, I have tried setting up the entry-criteria for a column by using an issue-type called "Entry Criteria" and a swimlane at the top that displays those. These criteria now counts towards my WIP-limits on each column (and by the way a WIP-limit for the entirety of the board would also probably be better in a lot of scenarios) although it's not really a work-item.

Of course having visible rules implemented would be better, but this is a good hack.

I imagine you could do similar things with similar hacks, however, it's not really desirable because the WIP-limits count everything.

So yes, you could ALWAYS count ALL your work-items towards this limit, however, maybe not everything on the board is an actual work-item, so I do think it's a pain in the ass this is not implemented.