A municipal benefits-calculator team comparing Extreme Programming (XP) with Scrum notices developers freely improve any module. Which XP practice does that reflect that Scrum does not prescribe as a core component?
Select an answer to reveal the explanation.
Short Explanation
XP treats the codebase like a shared kitchen—anyone can tidy a messy drawer. Collective code ownership (often with pairing) is an XP engineering habit Scrum never hard-wires. Scrum stays quiet on who owns which files; XP leans into shared craft.
Full Explanation
When a municipal benefits-calculator team comparing XP with Scrum notices developers freely improve any module, that reflects collective code ownership—an XP practice where the whole team shares responsibility for the codebase rather than siloed module owners. Scrum does not prescribe collective code ownership as a core component the way XP highlights that engineering practice. Recognizing the practice helps associates separate XP technical culture from Scrum’s framework set.
Mandatory two-week Sprints with a fixed Sprint Goal owned only by the Scrum Master fails conceptually because Sprint Goals are a Scrum construct and are not "owned only by the Scrum Master" as an XP collective-ownership explanation; this option misattributes Scrum rules to the XP observation. A separate architecture review board that must approve every commit before merge fails because that gatekeeping contradicts collective ownership’s shared responsibility model. A requirement that only the Product Owner may touch production configuration files fails because that is neither XP collective ownership nor a Scrum core engineering mandate.
Exam caveat: Collective code ownership is an XP emphasis; do not confuse it with Scrum events/roles or with restrictive ownership gates. Operational check: if the benefits-calculator team adopts collective ownership, establish shared standards, CI, and review norms so any developer can improve modules safely within civic security policy.