Over several releases, the cloud-services team has kept adding new Product Backlog items to its data-sync module without ever restructuring the existing code, and each new item now takes visibly longer to design cleanly, so which practice addresses this directly?
Select an answer to reveal the explanation.
Short Explanation
A module that just keeps getting features bolted on without ever being tidied up is like a closet that only ever gets more stuffed in — eventually nothing fits without a fight. Refactoring regularly, as part of doing the work rather than as a separate project, keeps the design flexible enough to keep absorbing new backlog items.
Full Explanation
Software design in Scrum is expected to emerge over time rather than be fixed once and left untouched, and refactoring is the practice that keeps a design capable of absorbing new requirements without becoming brittle. When a module accumulates additions release after release with no corresponding restructuring, its internal design gradually falls out of alignment with what it now actually needs to do, and every subsequent change has to fight that misalignment — which is exactly the slowdown described here. Treating refactoring as a separate future project outside of Scrum defers the cost rather than addressing it, and in the meantime every Sprint continues paying the tax of a worsening design. More detailed upfront specifications do not fix a structural problem in existing code, and deprioritizing the module doesn't remove the underlying design debt, it just delays when the team has to confront it. Sound practice folds refactoring into the regular flow of delivering Product Backlog items, a little at a time, so the design keeps pace with what is being asked of it. A useful check is to look at whether recent estimates for similarly sized sync-related items have been trending upward — a steady increase, despite similar complexity, points to a design that needs continuous attention, not just more careful planning.