WIP Limits broken by low-priority Stories - What to do?

Question

Current Situation

Small team of 4 developers and 2.2 QAs.

I'm trying to implement work in progress (WIP) limits.

There are currently many (37) Stories waiting for QA (also 22 currently being QA'd, but that's a separate issue).

Of these Stories, some of them are an entirely new application that isn't yet live. Most/all (I haven't checked) have been merged to develop branches but are alone so could always just delete develop and remake it from master. It's possible (though somewhat unlikely) some of them are merged into develop with other work, though.

Problem

Now, as per my understanding, as per how WIP limits should work, the team should be focusing on reducing those 'waiting for QA' Stories instead of heaping more Stories into the 'Waiting for QA' by developing more stuff.

Problem is, until now, the team has been working on things without much regard to priorities. So many (~2/3) of the Stories waiting to be QA'd are much lower priority than things that are waiting to be developed.

Question

So... what should be done? I can see these possibilities, but have no idea what is the best approach:

• Ignore the low-priority Stories (and, consequently, reasonable WIP limits) until sometime in the future when they can be addressed.
• Create some other field or column to hide the work until such time as it's relevant.
• Throw away the work and move the Stories back to Ready to Develop.
• Ignore priorities and get the work under WIP limits as soon as possible.
• Some solution I've missed...?

Answer 1

I have found that temporary fixes (like ignoring low-priority stories) often end up being long-lived.

Better to get your board to a good place first, then work to optimise the WIP limits.

The downside of this is that some high priority stories will be delayed, but the benefits include:

• Fewer items on the board, so it is easier to see what is going on
• It is easier to predict cycle times for stories as there is less clutter and no parked/hidden stories
• The team starts to think in a disciplined way, rather than being reactive in the short-term

So my suggestion would be to first clear as many stories through QA as possible. The developers could spend their time assisting with QA, tackling technical debt, writing automation tests, etc. This will reduce the inflow of new stories to QA while the backlog gets cleared.

Once the backlog has been cleared, settle on a relatively low WIP limit. Try that for a while and see how overall throughput looks. If necessary, tweak the WIP limit up, but always keep an eye on the impact on overall throughput.