How do we cap or limit the number of open issues?

David Hodnett

Does anyone know of a workflow, either Atlasssian provided or third-party provided, that allows us to cap the number of open issues that can exist at any one time?

In addition to the issues that we're (intentionally) working on during any one Agile sprint, we've also allowed our developers to add their ideas and suggestions for future consideration. As a result, our backlog is considerable and we're spending significant time and energy weeding out duplicates and obsolete tickets, and consolidating tickets where we can kill two birds with one stone. Until we get a handle on this, we thought it might be useful to adopt a rule where a user cannot create a new ticket unless he has resolved and closed a few existing tickets first.

We're not (yet) looking for a per-user restriction. We just want to be able to set the limit at say 600 open tickets so that our developers will be motivated to go back and "free up some space." As we make headwind, we'd like to lower that to say, 500 tickets, and then to 400, and so on until our overall process is working the way it's supposed to.

Thank you.

Nic Brough -Adaptavist-

Initially, that looks like a call for "column constraints", but it's definitely not.

I think you'll need code for this, and it won't be very pretty if you do it exactly this way.  The code is not too hard actually - you need to place a "Validator" on "create issue" that will

1. do a quick search for "unresolved issues reported by user"
2. do a quick search for (say) "issues resolved in the last 2 weeks by user"
3. Return "true" in some cases (number of issues resolved >= unresolved for example - that would give you a simple "one in, one out" rule - the more the user wants to raise, the more they have to fix)

The problem with that is that a user will actually have to click "create" and proceed with the creation before they get told "you have too many open issues, so I'm not going to create this".  I don't think there's a way around that.

The problem with most of this approach is that you might well lose good ideas and valid issues by blocking the creation of new ones.

I would be tempted to revise the workflow a bit.  Put a new status in at the beginning, with a name like "unexamined" and two transitions - one to "closed (because we won't do it)" and another to the first real status in the workflow.  Then I'd use the code from the validator above to create a "condition" instead, so that an issue cannot be started at all - the option is not shown to anyone until the user has resolved enough issues.  This does still leave you with the problem of de-duplicating and obsolete issue handling, but at least they are totally distinct from your accepted issues.