The parks tee-time team wants a dashboard of 30 metrics. How should the Scrum Master / Team Coach choose what to measure?
Select an answer to reveal the explanation.
Short Explanation
Thirty metrics is a fireworks show, not a flashlight. The tee-time team needs a few measures that test this week's improvement guess. A vanity wall just gives everyone something shiny to argue about.
Full Explanation
A parks tee-time team that wants a dashboard of thirty metrics should be coached to pick a few measures that match the team's current improvement hypothesis. Measurement without a question becomes decoration; too many metrics dilute attention from the municipal booking problem being improved and invite cherry-picking. Putting all thirty on a wall so leadership can pick favorites in the hallway turns the dashboard into hallway politics. Ranking the team against other parks teams on every metric at once recreates harmful cross-team score contests that SASM warns against. Asking the Release Train Engineer to publish a thirty-metric ART scorecard for tee times escalates noise to train level without clarifying learning. Exam caveat: SASM favors a small, hypothesis-aligned measurement set over metric sprawl, vanity walls, and league tables. Operational check: name the current improvement hypothesis (for example reduce no-show rate or booking lead time), select three to five measures that would falsify or confirm it, retire or archive the rest from the primary dashboard, and review those few in inspect-and-adapt with the parks team. Re-select measures when the hypothesis changes so the civic dashboard stays purposeful rather than ornamental.