Scrum: What do Developers do after all tickets have made it to QA?

Question

Let's say the sprint goal is to deliver V.2 of a software.

Development does their thing, moving items from In Progress to Peer Review.

Developers review their peer's work and move items to QA.

Let's say there's 2 more days in the sprint, and QA is on track to finish without issue.

There's nothing left to swarm at this point. What are some activities that don't threaten the committed increment, but provide value to the overall team/release/project that Developers could do?

Edit: I should mention that we do not follow the Scrum practice of "no sub teams." So let's also assume trained developers aren't going to also do the work of trained quality assurance analysts. I understand that's a scrumbut, but that's the reality of our situation.

Answer 1

Quick Summary: Periodic Downtime is an Agile Non-Issue, and Part of a Sustainable Cadence with Sufficient Slack

It doesn't really matter what the developers do during this downtime because unless the downtime is something that happens every Sprint, it's just the cost of doing business the way you're doing it. Agile budgeting should be done based on expected full-team iterations* rather than on individual person-hours associated with piece-work, so this is a total non-issue unless it's a chronic problem with your ScrumBut implementation or estimation practices.

---

*Example: 7 people at 40 hours a week for each 2-week Sprint is 560 person-hours per Sprint. You're either routinely (e.g. more often than not) delivering a Sprint Goal worth that per-Sprint cost, or the Product Owner, project, or client can choose to "fail early." If you're not thinking in terms of per-Sprint increments or validated learning, and are focused instead on 100% utilization, you're not just doing ScrumBut: you're doing agility wrong.

---

That said, there's always something useful for team members to do. I provide a very large (but by no means exhaustive) list of such things in the following section. Just keep in mind the goal is for the activities to be useful for both the individual team members and the team as a whole, not just busy-work to sweep the sequential nature of your testing process under the rug.

Analysis and Recommendations

There's nothing left to swarm at this point. What are some activities that don't threaten the committed increment, but provide value to the overall team/release/project that Developers could do?

Scrum isn't about swarming; it's about whole-team ownership of goals and the predictable delivery of incremental value. The framework is pretty non-prescriptive, and doesn't even require common agile practices like test-first development. While you're not really doing Scrum, I don't think that's your real issue here. I think you're experiencing an X/Y problem because you're thinking in terms of "doing all the things" rather than focusing on continuous improvement.

In particular, there is always some sort of project debt that can be paid down or paid forward. Some ideas to consider include:

• Cross-training to improve the T-shape of your Development Team members, such as:
  • having software developers and testers teach each other tools and techniques;
  • having UX/UI people learn more about how these things are implemented in the project's language;
  • having front-end developers learn more about about back-end development, or vice versa;
  • having Development Team members learn more about business analysis or requirements-gathering; or
  • having database developers learn more about the object-relational mappers (ORMs) the team leverages, or having them teach the developers SQL tricks that the ORM doesn't handle for them.
• Paying down technical debt in the form of:
  • more Backlog Refinement;
  • spending time on all those great ideas brought up in Sprint Retrospectives but that no one has time for when Sprints lack sufficient slack;
  • technical refactorings;
  • code reviews;
  • exploring seldom-touched or seldom-reviewed areas of the code base;
  • writing additional unit tests; or
  • updating developer laptops, software, and libraries.
• Assessing your architectural runway for:
  • possible improvements to your CI/CD pipelines;
  • capacity planning for upcoming requirements; or
  • tools, processes, and systems that would improve the team's productivity.
• Learning spikes, such as:
  • process spikes (e.g. "Let's try mob programming and see how that works for us!");
  • educational activities related to Scrum, team tools, the problem domain, or new language features;
  • demoing that shiny new IDE someone started using, but that no one else knows much about yet; or
  • show-and-tell where the developers get to show each other the most useful tweaks they've made or plugins they've added to their nvim, emacs, or RubyMine environments.
• Potentially-useful side projects (think Google's now-defunct "20% time" policy) such as:
  • building devcontainers;
  • replacing crufty or bloated linters with something the team likes better;
  • building a wiki for the project;
  • or anything else that has potential value for the team, project, or organization.
• Even "just learning something new" is often beneficial because stagnant developers either stagnate or leave. When you keep your team too busy to explore, learn, or work on professional development under the 100% utilization fallacy or its many variations, the organization eventually pays the price.

In short, it really doesn't matter what the team does with slack time so long as it isn't excessive. All projects require slack; the trick is to right-size the amount of slack you have, and to do something constructive with excess slack.

Key Take-Aways

If you take only only two things away from this entire post, memorize the following points:

1. Avoid creating busy work to reduce the visibility or transparency of your sequential testing process. Scrum (and agility in general) are about creating transparency, visibility, and predictability. Anything that reduces those OKRs is an anti-pattern.
2. Reward, don't punish, a team for being efficient or delivering faster than planned. Success is based on outcomes, not time or effort expended, so regardless of what your organization may think piling more work on people because they finished faster than expected is the exact opposite of how to create or keep 10x teams or high-performing individuals.

Slack is essential to effective processes (see pretty much all of queuing theory). If your process creates excessive slack (however you choose to define that) then fix the process; don't hide the problem or disincentivize your team to deliver ahead of schedule.

Answer 2

This type of situation adds a lot of risk. Just because "QA is on track to finish without issue" doesn't mean that they won't find a critical issue on the last day. This would leave you going into Sprint Review without a working, usable, potentially releasable product. It's not just the Scrum rule of no sub-teams being broken, but you are introducing a waterfall and at least one hand-off, which adds to waste in the process.

The real solution is to challenge this assumption that trained developers aren't going to do the work of trained quality assurance analysts. Lean and agile software development requires a drastic shift in mindset, including tearing down silos and reducing hand-offs. The long-term solution would be to teach the developers about testing and quality assurance practices. Build and test automation would be helpful, considering the unit, integration, and system levels for testing. TDD would be one practice to consider, but not a mandatory practice. Designing and building the system for testability and observability would be helpful, especially to reduce the burden on testers.

The short-term solution is to keep the developers free to respond to questions and concerns that come out of testing, especially late in the testing cycle. I would strongly advise against picking up new work. Instead, there are two areas to focus on. One would be refinement - preparing upcoming work and making sure it's well-understood. This could include some design and prototyping activities. The other option would be to look at the long-term solutions of making a truly cross-functional team and using the time to build the testing and quality assurance skills of the developers.

In the rare cases where independent quality assurance is necessary - which tends to be limited to the most critical systems - then the approach should be to move that independent quality assurance activity out of the Sprint. The definition of "potentially releasable" shifts to mean that it could be handed to the independent quality assurance team and be highly likely to pass their additional testing without issues and the Definition of Done would include inspection and testing activities to make that a reality.

Answer 3

Some things the developers can do:

• Design/architecture meetings
• Tackle technical debt (where it doesn't require much testing)
• Tackle code quality (using metrics like Findbugs, Checkstyle, etc.)
• Write automated regression tests
• Learning time - investigate new technologies, read blogs, etc.
• Create prototypes
• Knowledge transfer
• Update documentation