After Sprint Review, 311 request-status metrics show residents still cannot tell when a pothole will be filled. The Product Owner publishes a metrics PDF and leaves the Product Backlog unchanged. What is missing, and what should happen?
Select an answer to reveal the explanation.
Short Explanation
Reading the pothole dashboard and then changing nothing is like checking the oven temperature and leaving the cake to burn. Inspection is only half of empiricism. The Product Owner has to adapt the backlog when the evidence says residents still cannot see a fill window.
Full Explanation
Empiricism requires transparency, inspection, and adaptation together. After Sprint Review, when 311 request-status metrics show residents still cannot tell when a pothole will be filled, publishing a metrics PDF and leaving the Product Backlog unchanged is inspection-as-theater. The Product Owner should change Product Backlog order based on what was inspected so the next Increment better answers the fill-window question citizens need.
Claiming nothing is missing because publishing metrics fulfills empiricism even if nothing changes confuses reporting with adaptation. Having the Scrum Master rewrite the metrics PDF in a different template before any backlog change is allowed optimizes the report, not the product. Asking Finance to freeze the Product Backlog so metrics have a stable baseline for next year blocks the adaptation half of empiricism.
Public works credibility with residents depends on changing the backlog when status evidence says fill windows are still invisible.
Exam caveat: PSPO II treats inspection without adaptation as incomplete empiricism—especially visible in civic dashboards that never change ordering.
Operational check: within one day of the Review, reorder or slice backlog work that improves status clarity for pothole fill windows, and cite the metric evidence that drove the change.