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- · Accepted solution]

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.

[David Hodnett]

We completely agree with the sentiment. We're in this predicament because we were afraid to loose a good idea that occurred to us on the spur of the moment. When we resolve roughly 40 issues a month and our backlog is 600-plus issues, it occurs to us we might not be discerning enough. 

Your train of thought however prompted yet another idea. Is it possible to disable the create-issue button for all but one or two people - such as the scrum master? That way, if we're at the limit, a developer will have to tell the scrum master about the idea first (does it pass the sniff test?) as opposed to just jotting it down and moving on.

If that's not possible, I could see us adopting the conditional you proposed as a gateway...

[Nic Brough -Adaptavist-]

Absolutely - have a look at the "permissions scheme" for the project(s) - there's a line in there that determines who can "create issue". 

I'd set that to a role rather than a person - if you create a new (global) role of "can create issue", then the project administrators can add people to it (a scrum master is often a project administrator).  So that way, the scrum master could start with themselves in it, and later add people they trust not to just spam it with too many issues.