The firmware Developers on a home-robot product each work on their own long-lived branch and only merge everything together on the final day of the Sprint, which regularly produces last-minute merge conflicts and broken builds, so which change would most directly address the root cause?
Select an answer to reveal the explanation.
Short Explanation
Merging code only on the last day is like a group of roommates each redecorating a room all month and only opening every door on move-in day — of course things clash. Integrating small changes into one shared mainline continuously, instead of hoarding them, surfaces conflicts while they're still small and easy to fix.
Full Explanation
Scrum does not mandate any specific engineering practice, but continuous integration is a widely used practice that directly supports the Scrum Team's goal of finishing a usable, integrated Increment inside the Sprint's timebox. When Developers integrate frequently — ideally multiple times a day — into a shared mainline, conflicts between changes surface early, in small and manageable pieces, rather than compounding into one large, high-risk merge at the very end. Waiting until the last day concentrates all of that integration risk into the moment when there is the least time left to resolve it, which is precisely why builds break and Sprint Goals get jeopardized right before Sprint Review. Neither extending the Sprint nor routing merges through the Scrum Master or Product Owner addresses the underlying cause: the Scrum Master isn't accountable for how the Developers manage their technical workflow, and the Product Owner's accountability is value and ordering, not code integration. A practical check for the team is to track how often the mainline build is broken or how long branches live before merging — branches open for days at a time is a reliable early warning that integration is happening too rarely.