The tree-removal-permit team is arguing solutions before anyone agrees on the problem. What powerful question should the Scrum Master / Team Coach ask?
Select an answer to reveal the explanation.
Short Explanation
Picking a chainsaw before you know whether the job is a stump or a sidewalk crack is how you wreck the street. "What problem are we actually solving?" parks the solution pile until the permit team shares one problem. Speed-to-code is not the same as solving the right thing.
Full Explanation
A powerful question can interrupt premature solutioning and restore a shared problem statement. When the tree-removal-permit team argues designs before anyone agrees what resident or inspector pain they are solving, the Scrum Master / Team Coach should ask what problem they are actually solving so the group re-centers before picking a design. That question surfaces outcomes—safer removals, clearer applicant guidance, fewer incomplete submissions—before architecture or coding races begin.
Asking who can code the fastest option by Friday fails by concept: it rewards speed of implementation over problem clarity and locks the team into the first plausible build. Asking which vendor already sold the city a solution fails by concept by outsourcing problem definition to procurement and conflating purchase history with resident need. Asking why the Release Train Engineer has not already picked the architecture fails by concept: train-level facilitation is not a substitute for the team's own problem framing on permit work.
Exam caveat: SASM coaching skills emphasize powerful questions that promote shared understanding before solutioning; prescribing architecture or vendor choices is a common anti-pattern. Guidance on options is fine once the problem is clear—the tree-removal-permit team and Product Owner still own problem definition and design choice.
Operational check: pause the design debate, ask the problem question aloud, capture a one-sentence problem on the board with the team, confirm inspectors and applicants are represented in that statement, then resume design only against that shared problem, and verify the next refinement starts with problem clarity before solution sticky notes appear.