A firmware Developer is split 50/50 between the home-robot Scrum Team and an unrelated legacy-product team, and the robot team's Sprint Backlog repeatedly stalls waiting for that Developer's availability. What should the Scrum Master do?
Select an answer to reveal the explanation.
Short Explanation
A Developer split across two teams is like a phone with two people trying to use it at once — something's always waiting on hold. The fix isn't quietly working around it; it's naming the split allocation as the real bottleneck it is and raising it as an impediment to whoever can actually change it.
Full Explanation
Part-time, divided attention is a well-known source of Sprint Backlog drag, and the Scrum Master's mechanism for addressing it is the same one used for any organizational impediment: make the cost visible and escalate it to whoever has the authority to change the assignment. Planning around the unavailability every Sprint treats a structural problem as a permanent constant, which normalizes the very thing that's hurting the team's ability to meet its Sprint Goal. Quietly reassigning work without discussion hides the real cause from the team and from whoever assigned the split, so the same conflict recurs the following Sprint with no chance of being fixed at the source. Pushing the Developer toward unpaid overtime treats a resourcing problem as an individual sacrifice rather than an organizational issue, which is neither sustainable nor the Scrum Master's call to make. A useful operational check: track how often the Sprint Backlog stalls on this Developer's availability across a few Sprints and bring that pattern, not just a one-time complaint, to the conversation about the allocation.