How to balance the QA load during the Sprint?

  • There is an iterative development (let's call it “Scrum - with reservations” for simplicity) of a team of 12 people: 3 back-end developers, 3 front-end developers, 1 technical writer and 5 testers (4 manual and 1 on automation).

    The automation tester is engaged in the automation of the regression tail and has just started setting up the framework, the technical plug-in describes the system and is not rigidly attached to the development cycle.

    The client himself forms the requirements and describes them in tickets. There are weekly iterations (at the insistence of the client - he wants to regularly receive deliveries).

    QA has an uneven load: in the early days of the sprint, there is almost no work (update test cases and checklists, in fact they are loaded by 25-30% and in the last days of the sprint increases significantly: the regression takes all 4 QAs up to 6 hours).

    The team makes the code freeze in PN during the day (release - on Wednesday), tries to break down the requirements into relatively small parts for writing code (up to 1 day).

    What else can be done to balance the load of the QA team during the sprint?

  • Analysis

    In most agile frameworks, load-leveling of individual resources is a known anti-pattern. It is a variant of the 100% utilization fallacy, which generally leads project leadership to favor individual busyness over full-team collaboration and predictable delivery.

    Effective project management requires process slack. Agile frameworks generally make this requirement visible and explicit, while the implementation of more-traditional frameworks often treat slack as optional (if the frameworks acknowledge the importance of slack at all).

    Furthermore, agile principles require ongoing collaboration. Skill silos within the team's internal process create hand-offs that create project drag and quality issues. That's why most agile frameworks work best with cross-functional (aka T-shaped) team members, collective ownership, and full-team collaboration.


    The entire project team must work together to inspect-and-adapt the process. While implementation details may vary between organizations, projects, and teams, significant long-term efficiency improvements will generally come from:

    1. Assigning work to the team rather than to individuals.
    2. Optimizing process slack to treat team capacity as an upper bound rather than a management target.
    3. Involving the whole team all phases of the work to provide visibility and cross-training.
    4. Adopting a test-first development strategy to meet INVEST criteria, improve product quality, and bake in the Definition of Done.
    5. Allow mature teams to self-organize around internal processes and task collaboration, rather than imposing workflows or individual assignments.
    6. Coach immature teams on how to inspect-and-adapt their own processes.
    7. Ensure management is coached on the need to invest in continual process improvement and team empowerment if they want to reap the benefits of an agile framework.
    8. Make sure that sustainable processes and continuous improvement are treated as more-important values and metrics than the appearance of productivity.
    9. Allow teams room to learn from empirical processes by ensuring that goals, targets, and forecasts are treated as iterative learning opportunities.
    10. Remove "failure is not an option" from the organization's vocabulary. Teams that aren't allowed to fail can't improve, and generally don't succeed in the long term.

    There are certainly other things to unpack about your choice of frameworks, team composition, leadership matrix, and organizational values. This list isn't meant to be comprehensive. Treat it as a starting point, and invite your team members to actively participate in the analysis and problem solving.

    A bottom-up approach (within the confines of the chosen framework) is a non-negotiable aspect of effective agility. Top-down, command-and-control management is inherently non-agile, and will never yield the expected results from an "agile" implementation that isn't.

Log in to reply

Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 4
  • 2