Jira board limits: are they a good idea?

[#1]

Many in DevOps suggest adding limits to Jira board columns, but do they really work? To answer that question, let's start by looking at how a limit works.

Configuring board columns

When configuring your board's columns, you can add a minimum and maximum value for the optimum number of issues with statuses assigned to the column. These are arbitrary values, and give a visual indication on the column when the limits are reached. Importantly, they don't stop you from going beyond these limits. The limits only indicate that you may want to look at the issues in the column. Maybe you can reassign to a different status, or perhaps get additional resources to move an issue to another column.

You can add limits to any board column, but the most common is called WIP (Work in Progress). By assigning limits on the number of items that can be in progress at any one time, you focus on what is achievable right now. They also provide greater visibility on potential blockers. There's a good explanation on the Atlassian Agile Coach site.

What is a good WIP limit?

Ah, the million dollar question to which I don't have the magic answer. It depends on things like:

• Your corporate setup
• Processes and working practices
• Dependencies on internal teams or external companies
• Resource levels

In fact even if I did have an answer to what is a good WIP limit, the chances are my answer would change in the weeks and months ahead. This is OK, as it is good practice to constantly revisit your Jira boards to ensure they meet your needs. Part of this is looking at your WIP limits.

Do WIP limits really work?

As previously mentioned, the limits don't stop you from adding an issue to a column if the limits are reached. So what do they add?

Don't just set and limit and left there for all eternity. Things change, and that's OK. Looking at your limits should be part of your regular analysis. Include a discussion as part of a retrospective or team meeting.

An example

We started using a maximum WIP limit of 25 about three months ago. We didn't set a lower limit. This worked well, with only occasional instances of reaching the limit.

However, our team is heavily dependent on other internal teams to move issues across the board. For example, we get all our work reviewed both internally and externally. Our work is also reactive, we're a team of Technical Writers, with our issues created in our project as a result of work developed by the engineers. Communication between us and other teams is critical to our planning process, but occasionally the WIP limit is insufficient.

Recently we had an issue to address some legacy content that hadn't been touched in years. As a result of recent content strategy changes, it wasn't just a simple correction or clarification change. It required a complete rethink over how the content was structured, written, and displayed. Cue 20+ issues being created, most of which being worked on by the team at the same time. All of a sudden the dreaded red column was perpetually present. 

We've temporarily increased the WIP limit. Once the 20+ tickets are complete, we'll revisit the limit again.

How about you?

In the spirit of sharing information, I'm curious to know how you handle your WIP limits. Do you adopt a different strategy? Do please share what you can.

[Athas Mark]

For teams with low interrupt, WIP can help enforce behaviors such as pairing.  For teams with a high level of blocking stories--stories where customer value is not attained by splitting the story--WIP can encourage team Devs to go idle--an anti-pattern.  It depends on the team, where they are on their maturity journey.  It may be a great tool to adjust team behavior, but it may also not be effective long-term.  We seek to develop the Agile Mindset, rather than put out 'external controls,'  but again, WIP can be valuable as a growth tool that would help develop the Scrum value of Focus.

[Robert Wen_Cprime_]

I. LOVE. WIP. LIMITS.  They really help my team get focused.

In my Scrum Master days of yore, I'd set up WIP Limits with the team and put it on the Working Agreement.  My job would be to see if they were effective or needed to be lowered, based on looking at the Cumulative Flow Diagram to examine bottlenecks.  Adjusting WIP limits does make for good retrospective fodder.

[Colum McAndrew]

Out of interest, does anyone add a limit to another column other than In Progress? It also seems that folk add a maximum limit more than a minimum limit. It would be interesting to know if you buck either of these trends.

[Bill Sheboy]

Hi @Colum McAndrew 

For teams I have supported, going over "WIP is the leading indicator for lead time..." doesn't help without additional chats to progressively build up knowledge.  Instead we stick with simpler ideas on the impacts of task switching, knowledge silos, WIP debt, and Age of WIP.

Some teams I support have their entire workflow (concept to cash) on the board, and so have several different WIP limits set.  Unfortunately Jira does not support WIP limits across multiple columns (e.g. X-doing and X-done), so multiple limits on the board creates other challenges.

Kind regards,
Bill

[Nik Lewis]

We have a reasonably complex board where we control what is shown via Quick Filters.
It would be great if the WIP limits applied only to what the filters show.. however I don't believe that this is the case. 
Has anyone experienced this / have a solution?