During a Sprint, a production incident shows a high-value fix for the utility outage map outranks a planned cosmetic story. What is an appropriate adaptive response?
Select an answer to reveal the explanation.
Short Explanation
New info, new order—like clearing a crashed car before finishing the street mural. The Product Owner holds the ranking pen; they can elevate the outage-map fix and adjust Sprint work within capacity. Adapt, don’t pretend the old list is sacred.
Full Explanation
During a Sprint, when a production incident shows a high-value fix for the utility outage map outranks a planned cosmetic story, an appropriate adaptive response is to reprioritize with Product Owner authority so the higher-value fix can enter the Sprint Backlog as capacity allows. Adaptive teams expect reordering when new information changes value, and the Product Owner owns that priority decision within capacity realities for civic reliability.
Ignoring the incident until the next annual planning cycle six months away fails conceptually because outage-map defects that affect residents cannot wait for annual planning. Letting any developer silently swap priorities without Product Owner involvement fails because backlog order is a Product Owner accountability, not silent individual preference. Cancelling adaptive work forever and rewriting a full predictive baseline overnight fails because one incident does not require abandoning the adaptive approach entirely.
Exam caveat: Mid-sprint high-value emergents are handled through Product Owner reprioritization and capacity trade-offs—not annual delay, silent developer swaps, or abandoning adaptive methods. Operational check: the Product Owner pulls the outage-map fix into the Sprint Backlog by swapping or reducing lower-value work, informs stakeholders of the trade, and keeps the cosmetic story deferred.