With three weeks left before a big-box retailer's launch deadline, a director asks the Scrum Master to add two new Developers to the firmware team in the middle of the current Sprint to speed up certification work. What should the Scrum Master do?
Select an answer to reveal the explanation.
Short Explanation
Throwing new people at a Sprint that's already underway rarely speeds things up — new teammates need ramp-up time and pull focus from the people already delivering, so the short-term cost often outweighs the long-term gain. A good move is naming that trade-off honestly and lining up the change for the next Sprint Planning instead of forcing it mid-flight.
Full Explanation
This tests understanding that team composition changes carry a real, temporary productivity cost — new members need context, existing Developers spend time onboarding them, and the current Sprint Backlog was planned around the existing team's capacity, all of which the Scrum Master should surface honestly rather than pretend away. Adding Developers immediately assumes more people linearly speeds delivery, ignoring the ramp-up and coordination overhead that typically slows a Sprint down before it speeds anything up. Refusing outright and claiming headcount can never change overstates the Scrum Master's authority and isn't accurate — team composition can change, just not for free and not without the team's involvement. Silently adding people without discussion strips the Developers of a say in how their own team is shaped, undermining self-management at exactly the moment it matters most. A concrete operational check: if the organization insists the change happen sooner, have the team explicitly re-plan the Sprint Backlog and, if needed, discuss the Sprint Goal with the Product Owner, rather than absorbing new people invisibly into an unchanged plan.