Field staff on the hydrant-mapping team disagree about what "done" means. What should the Scrum Master / Team Coach ask?
Select an answer to reveal the explanation.
Short Explanation
Abstract debates about "done" go in circles; a hydrant a firefighter could find last Tuesday does not. Ask the team to point at a story that was truly usable in the field. Quality gets concrete when you can picture the user.
Full Explanation
Experience-based questions clarify Definition of Done better than abstract argument or principle recitals. When field staff on the hydrant-mapping team disagree about what "done" means, the Scrum Master / Team Coach should ask them to describe a recent story that firefighters could actually use in the field so done is grounded in experience. That grounds acceptance in operational usability—accurate locations, usable offline behavior, trusted attributes—rather than ticket closure theater.
Asking who wants the loosest definition so more tickets can close fails by concept: it optimizes throughput of incomplete work over firefighter-ready maps. Reciting a SAFe principle number until agreement appears fails by concept: principles inform practice but do not replace concrete done criteria for hydrant data. Waiting for Product Management to publish a 40-page done policy before the next sync fails by concept by delaying team ownership of a usable, living Definition of Done.
Exam caveat: SASM facilitation favors concrete, experience-based questions to align quality; abstract policy dumps and principle recitals are distractors. A short written Definition of Done is still valuable—the path to it should start from field-usable examples on the hydrant-mapping team.
Operational check: ask for a firefighter-usable example story, extract done criteria from that example onto a visible checklist, trial the checklist on the next story, refine with field feedback, and verify disagreements drop when done is stated in operational terms.