Acceptance criteria on a permit-status Product Backlog item specify exact pixel positions, hex colors, and a 12-pixel font. Developers say they cannot inspect value—only compliance with a mockup. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
Telling the crew which brick sits on which millimeter is not the same as saying the resident can see permit status without calling. Capture the outcome and the test; let Developers use craft—and the Definition of Done—for the pixels. Specs that only describe mockups hide whether the work helped anyone.
Full Explanation
Product Backlog items should express user and value intent, not only pixel mandates. When acceptance criteria on a permit-status item specify exact pixel positions, hex colors, and a twelve-pixel font, Developers can inspect mockup compliance but not whether residents can understand status without a trip to the counter. The Product Owner should reframe the item toward user outcomes and testable intent, leaving UI details to Developers within the Definition of Done. Expanding the pixel instructions into a full visual-design contract before any Increment substitutes output compliance for value learning. Removing all acceptance criteria because outcomes cannot be tested deletes the test of done-enough for the item. Copying the city’s brand PDF into the Product Goal and treating that as the item misuses the Product Goal as a style guide. Exam caveat: accessibility and brand constraints can appear in the Definition of Done or as non-functional acceptance; they should not replace outcome intent. Operational check: rewrite criteria around resident comprehension and self-service completion, keep visual polish as team craftsmanship under Done, demo the Increment against outcomes in Sprint Review, and refuse pixel-only “done” for the civic permitting product.