After three Sprints of discovery on a building-permit workflow, several core assumptions failed. The original release narrative is now wrong. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
Discovery that proves the permit idea is wrong is not a wasted three Sprints — it is the city dodging a bad build. Change the story and the forecast. Sunk cost is how offices ship the workflow nobody should use.
Full Explanation
Failed assumptions after three Sprints of discovery on a building-permit workflow are evidence; they must change the release narrative and the forecast. The Product Owner revises the story council hears because protecting the original narrative to justify sunk discovery cost converts learning into waste. Adding failed spikes back onto the Product Backlog as mandatory scope to recover the investment reinflates disproven work and crowds out higher-value permit paths. Asking Developers to implement the original design anyway so the three Sprints were not a loss doubles down on a plan inspection already rejected. Empiricism exists precisely so Product Owners can kill or reshape a bet when the Increment shows the assumptions will not hold for residents or staff. Exam caveat: sunk-cost defense of a release narrative is a classic distractor; maximizing future value outweighs defending past spend. Operational check: list which assumptions failed, rewrite the release narrative and ordered backlog accordingly, brief council on what changed, and confirm no disproven design work remains as mandatory scope. For building-permit discovery, failed spikes are learning assets only when the Product Owner changes the narrative and backlog; otherwise the city pays twice—once for the spike and again for implementing a disproven design. Confirm council materials no longer defend the original release story after the evidence lands.