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?


2 Answers 2



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.


If I understand correctly, you have 6 developers and 4 testers (I'm excluding the automation engineer because they aren't doing work in the sprint from your description). You say that the developers are completing pieces of functionality in as short as a day, so some work should getting tested early on. It is also clear that regression eats up a lot of time at the end of the sprint. These bottlenecks happen because you have people tied to tasks and there are, generally, two ways we can approach this (or a combination of both): spread the load and re-order the tasks.

Reorder the Tasks

The team could experiment with a form of test-first development. Behavior-Driven Development and Test-Driven Development (the two are best used together) are the most common approaches to this, but not the only ones. In it, you write tests for functionality before you write the code and then you write the code to fulfill the tests. This is ideally done in an emergent way (rather than writing all tests first) so this means that the tester would help the developer identify the main test case, then the developer would code to it. Then they would create the next test case - either for expanded functionality or for negative and edge cases. This way it becomes a collaborative process, rather than a staged one. Technically, both of these practices require the creation of automated tests, but I've seen teams have some initial success even without automation.

One side effect of this is that a lot of tests move closer to the code under test. Decision-logic testing moves to the unit test level, integration tests are still a different thing than unit tests, but a lot of times they use the same tools. This means your testers will be looking at code more, but most are used to it in a few days and the developer is right there with them to help explain. In the end, this results in a much more sustainable test suite.

Spreading the Load

There are a number of places in your description that you could spread out work. First and probably easiest is asking developers to help with the regression. Certainly, testers and developers have different skills and I'm not of the opinion that a developer can do all the testing, but regression is usually following scripts - let the developers take some of that work.

Next, if you try test-first development, you may find that it's easy enough for the developers to hook up the framework to allow the test steps to run automatically while they are writing the code. Doing this with the input of the automation engineer will have huge payoffs. Most developers don't write code that is easy to integrate automate testing into, but doing so isn't hard or significantly more work if you know what you are being asked to automate.

Finally, about half of the code you write in test automation can be learned in a few days. After that the learning curve gets very difficult. Testers can use some of their light time pairing with the automation engineer or developers to start building those skills (or get an expert in to do a workshop to train them). 4 testers and 6 developers can create new features way faster than 1 automation engineer can automate them. Most teams I see who set this on one person quickly bury them with a pile so deep they eventually give up.

There is a lot that can be done. Staged development with rigidly-defined roles is a very efficient way of working, but it doesn't scale down well. When developing in short increments, you are purposefully trading out some of that efficiency in exchange for working software that you can quickly put in front of the user and make sure you're building the right thing in their eyes. To get this, you need to lose the rigid structures.

  • I like your answer, but I question the statement that ”[s]taged development with rigidly-defined roles is a very efficient way of working[.]” I think it works well on assembly lines, but question its applicability to knowledge work or software development. I’d upvote this answer if I could find some context in which I could agree with that statement.
    – Todd A. Jacobs
    Commented Oct 26, 2019 at 17:43
  • @Todd - Perhaps my intended meeting didn't come through. Defined process control is a more efficient way of doing work when it can be applied. Unfortunately, defined process control is not applicable in the type of "each time is a bit different" work of software development, meaning that attempting to apply it ends up costing more, hence the benefits of things like Scrum. However, it can still feel like you are moving to a less efficient way of working if you are used to a defined process.
    – Daniel
    Commented Oct 28, 2019 at 2:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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