Help! QA is Slowing Down Our Agile Teams!

Ethan said, “In our org we have almost the entire team at this point embedded into a single scrum team, except QA. Its been pointed out by the team that its not exactly “fair” that a outside entity can block the team from burning down story points. If the QA is overworked, on vacation, etc then we can’t get that story burned down.

I’ve pushed back on the team to stop looking at story points as something to be earned but rather a capacity for what the team could get accomplishment…its a tool, but not a hammer. More like a stud finder with built detection for problems like electrical wires. Ive actually pushed them to think more like a startup.Be upset that something is blocking from getting your feature into the clients hand, not that the team loses some figurative points in the system.  In any case, just curious what the community does to approach this? Theres some obvious ones but id like to get your insight.”


From my perspective, it seems like a first order problem (organizational impediment) for you to solve for is the fact that QA is not a part of the team.

When we talk about cross functional scrum teams, we are looking for fully intact teams that have all the skills necessary to take functionality from an idea to the customer’s hands. If QA needs to be a part of this equation and they are not, its an organizational impediment you need to solve for.

Additionally, if there is an estimate in story points that can not/does not include qa because they are separate from the team or part of a different org structure, you are not going to get the “yesterday’s weather” value out of forecasting with story points the way you might expect. Velocity, in this case, means little because we can’t get stories to “done”.

Here are some suggestions for trying to solve your separate QA problem:

  • Suggestion 1:  Try to get ALL of qa integrated into ALL of the scrum teams as full fledged members.

    In other words, take a sledge hammer to the silo, remove your teams primary impediment, get rid of the handoff, incorporate QAs views into the estimating process, and remove QA as a bottleneck.

  • Suggestion 2:  Have the developers use automated unit testing, automated acceptance testing, and manual functional testing to get items to “done”.

    If you cant get QA to join your teams, build the QA skill internally. Use dedicated QA where necessary as “quality consultants” as you grow this skillset in your current team.

  • Suggestion 3:  Invite the outside QA groups (or a representative) to your sprint planning meetings so that you can give them some visibility into what you need and when.

    If they are involved in the planning process, you can more easily coordinate with them as an outside dependency.

Hope some of these suggestions are of value

There was an issue loading your timed LeadBox™. Please check plugin settings.

Leave a Reply