One Test Environment, Four Teams
Four teams of 4, 5, 6 and 4 Developers build one claims platform for a single Product Owner. Each has its own Scrum Master and two-week Sprints. All four must run end-to-end tests in a single shared staging environment before an Increment can meet the Definition of Done. Access is granted in half-day slots, the queue averages eight working days and has peaked at fourteen. Teams book slots speculatively and cancel often; two teams have started keeping long-lived branches. Defects found in staging are assigned to whichever team's code is suspected, and about 30% bounce back between teams. Escaped defects have doubled over two quarters. Leadership's proposed remedy is a fifth team of testers plus a two-week 'integration Sprint' after every fourth Sprint. Last month one team's Sprint Review showed an Increment that had never been run in staging.
1. Diagnose the problem. Is this a capacity shortage, a flow problem, or something else? What evidence supports your diagnosis?
Read the worked answer
Primarily a flow and ownership problem with a hard constraint at the environment, not a headcount problem in testing.
Evidence:
- A half-day service with an eight-day average queue means waiting dominates work. Adding work to a queue this long makes it longer, not faster. The constraint is environment throughput and availability, not the number of people who could run tests.
- Speculative bookings and frequent cancellations are classic behaviour when a scarce resource is allocated by reservation rather than pulled by work. The queue is being managed politically rather than by flow.
- Long-lived branches and 30% defect bounce-back are integration-cost symptoms. The longer code lives apart, the more expensive the merge and the harder it is to attribute a failure to a team.
- An Increment shown at a Sprint Review that never ran in staging is the transparency failure at the end of the chain. Either the Definition of Done is not being applied or it is being quietly waived.
- Escaped defects doubling while staging is congested is consistent with teams skipping integration under pressure, which is exactly the wrong adaptation.
A capacity argument would need evidence that the environment is full of useful work all day. Nobody has presented that. What has been presented is an eight-to-fourteen-day wait for half-day slots, which usually indicates batching, speculative reservation and no automation.
2. Evaluate leadership's proposal of a dedicated test team and a recurring two-week integration Sprint. What would you propose instead, and what would you escalate?
Read the worked answer
Both proposals treat symptoms and both make transparency worse.
Problems with the proposals:
- A separate test team institutionalises the handoff that created the queue. It adds a group that cannot change the code it is testing, so defects still bounce back, and it does nothing about environment throughput.
- An integration Sprint every fourth Sprint is a hardening phase by another name. It means three Sprints in four produce work that is not demonstrably integrated, and it delays feedback to the point where defects are expensive. It also breaks the Scrum expectation that each Sprint produces a usable Increment meeting the Definition of Done. Renaming a hardening phase does not make it compatible with empiricism.
What to propose instead, in order of leverage:
- Reduce batch size and integration frequency. Trunk-based development with feature flags, so integration happens continuously rather than at the end.
- Automate the end-to-end suite and make environments reproducible - containerised or on-demand environments created from infrastructure-as-code. This attacks the constraint directly instead of rationing it.
- Stop speculative booking. Make the queue visible with a pull system and cap work in progress per team.
- Keep testing inside the teams. Developers own quality; the Definition of Done includes automated tests and a green end-to-end run.
Escalate as organisational impediments: environment funding and platform engineering capacity, and the fact that leadership is being offered a structural fix rather than a staffing patch. Raise it with a costed comparison, and expect the integration-Sprint idea to survive unless the alternative has a date and an owner.
3. Until the environment situation improves, how should each team treat its Definition of Done and its forecasts?
Read the worked answer
Do not weaken the Definition of Done; change what the team commits to and make the wait visible.
The temptation is to relax the DoD so work counts as done without a staging run. That would repeat the failure already visible at the Sprint Review, where an Increment that had never run in staging was presented as if it were complete. It would also push defects later and make forecasts even less reliable.
Instead:
- Keep staging in the DoD and treat the queue as an explicit part of the forecast. If the average wait is eight working days in a ten-day Sprint, a team cannot honestly plan to integrate late-Sprint work. That arithmetic should drive Sprint Planning, not be discovered afterwards.
- Pull integration work earlier. Plan the Sprint so that the item most likely to break integration gets the early slot, and reduce the number of items in flight so the team can integrate incrementally.
- Publish the queue data - wait time, cancellation rate, utilisation - in the Sprint Review. Stakeholders need to see the constraint, not just hear about it.
- Flag unverified work explicitly. If something has not run in staging, it is not in the Increment; say so at the Review rather than showing it.
- Forecast in ranges and state the assumption. The most likely outcome is a range whose width reflects environment risk. A single date presented under these conditions is a guess wearing a suit.
Forecasts improve when the constraint is visible and attacked. They do not improve because a team promises harder.