The companion-app Developers rely entirely on manual testing performed in the final two days of every Sprint, and this manual pass has become the team's biggest bottleneck to finishing items by Sprint end, so what practice would most directly relieve this bottleneck?
Select an answer to reveal the explanation.
Short Explanation
Manual testing squeezed into the last two days is like trying to proofread an entire novel in one sitting right before it ships — everything piles up and the pressure guarantees mistakes get missed. Automated tests that run continuously as the code changes catch problems the moment they appear, instead of stockpiling all the checking for one exhausting crunch.
Full Explanation
A test pass that only happens at the very end of the Sprint concentrates all quality feedback into a narrow window with little time to react, which naturally becomes a bottleneck as the team runs out of runway to fix what it finds. Automated testing spreads that feedback across the whole Sprint: as Developers write or change code, tests run continuously and surface regressions immediately, while the relevant context is still fresh and there is still time to respond. This is a supporting engineering practice rather than a Scrum Guide requirement, but it directly serves the Scrum Team's need to reliably produce a Done, usable Increment within a fixed timebox. Pulling in less work sidesteps the actual problem rather than solving it, moving testing to an external team fragments accountability that the Developers should hold together, and shortening acceptance criteria simply lowers the bar rather than fixing the workflow that makes verification so slow. A concrete check is to measure how many defects are found in the final two days versus throughout the rest of the Sprint — a heavy skew toward the end is the signature of a manual, batched process rather than continuous automated feedback.