2

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...?
  • A couple of questions. Is "Waiting for QA" work been integrated? Or is it pending integration? How about the stuff in QA - do you QA before or after integration? If things are integrated into a revision of a product, it's probably easier and safer to proceed than attempt to remove pieces of the work one by one and not disturb known good functionality. – Thomas Owens Jun 11 at 0:41
  • How high priority is the new work on the backlog? Is it "stop all work, do this now" priority, or is it just normal work that would end up ahead of the current work if both were still on the backlog? – Bart van Ingen Schenau Jun 11 at 7:06
  • 1
    @ThomasOwens updated Question. Also, we do QA after integration to develop. When we go live with a revision, we merge develop to master. – Sarov Jun 11 at 13:07
  • @BartvanIngenSchenau In-between. It's "this project isn't due for a few months, but if it's late people are fired". – Sarov Jun 11 at 13:08
2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.