I'm a huge proponent of smaller Project Backlog Items (PBIs). Most of the pushback I get these days is: this will cause duplicated work for QA if we split the work into smaller PBIs. This would usually be the case for a portion of the QA work, but splitting the PBIs gets the work into Continuous Integration (CI) faster and gets it in front of many other parts of the organization which could be affected by the changes. What's the best way to handle large PBIs in this scenario?


What Daniel said, Automation, automation, automation.

QA can never keep up with development with manual testing, it's just not possible. We've seen QA be the bottleneck on projects for over 30 years.

What QA can do is take their expertise and apply it to creating automation.

Now QA is likely to push back on this if you just tell them to do it. Instead, approach it with questions.

For example?: - How do you think Amazon can make hundreds of production changes a day? - If we management mandated daily releases, how would we change our current test practices to meet the demand?


One approach would be to split the PBIs into smaller PBIs, but then still attempt to work on them close to each other, so that QA can test them both if they're both development-completed within the same CI cycle. If they don't get development-completed within the same cycle, then either QA needs to not approve the first ones (hence putting them off to the next cycle) or else QA just needs to duplicate their testing.

Just keep in mind that you're not splitting those PBIs so small that they violate INVEST. Especially the 'V' and 'T' portions. If the PBI does not provide value on its own, rhen you went too far. If the PBI cannot be tested on its own, then you went too far (or not far enough, depending).


This is a common argument along with the corresponding development one: this will be more efficient to develop together. It should throw up a red flag, but don't dismiss it, because the team can also be right.

There's a balance between working efficiently and delivering value quickly. Is the team still finishing the backlog items well within the sprint? One good rule of thumb is that the average backlog item should be completable in 2 - 3 days. You'll have longer and shorter, but that should be your median time.

If the backlog items are still too large, perhaps ask the team what the most efficient way to break it up is where they still have value. Maybe they have other ideas.

Finally, there's test automation. In Agile development, you always have to retest things as you iterate on the functionality. That's where test automation can really help. If your team automates at least the overlapping tests, the retesting effort is minimal.

  • 1
    Piggybacking off this answer, I'll add the question: what can you (collectively) do to reduce the overhead of an item from the "QA" point of view? – yitznewton Aug 31 '17 at 14:19

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.