A new Developer joins the firmware Scrum Team at the start of a Sprint, and within days the team's usual pace visibly slows as existing Developers spend time explaining context and reviewing the newcomer's early work. A stakeholder asks the Scrum Master why the team suddenly seems less productive. What is the most accurate response?
Select an answer to reveal the explanation.
Short Explanation
Bringing on a new teammate is a bit like merging into traffic — everyone slows down for a moment so the new car can find its lane safely. Naming that dip as a normal, temporary cost of onboarding is more honest than pretending team changes are ever completely free.
Full Explanation
This tests recognizing that team composition changes carry a real, temporary productivity cost as existing members share context and the new Developer builds working relationships and understanding of the product — that's a normal dynamic worth naming plainly to stakeholders, not something to hide or apologize for. Framing the new Developer as underperforming misdiagnoses a predictable onboarding curve as an individual failure, which is both inaccurate and likely to damage the newcomer's confidence and standing with the team. Insisting that adding people should never affect pace denies well-understood team dynamics and sets an unrealistic expectation that will just generate more stakeholder frustration when reality doesn't match it. Dodging the question entirely leaves the stakeholder without the transparency they're owed and misses a chance to build trust by explaining a normal trade-off honestly. A concrete check: track whether the team's pace recovers over the following one or two Sprints as the new Developer ramps up — a lasting slowdown would suggest something more than ordinary onboarding is going on.