How do you establish a Sprint Goal in planning?

WHAT THIS TESTS: This question tests your agency, collaborative skills, and understanding of first principles in Agile. The interviewer wants to see if you are a passive "ticket-taker" or an active, value-driven partner who takes ownership of the team's focus. It's a test of leadership and influence, not just process knowledge. You're being evaluated on your ability to facilitate a positive outcome when the process isn't being followed perfectly.

A GOOD ANSWER COVERS: A strong answer outlines a constructive, three-step approach. First, ask clarifying questions to find the common thread. Instead of looking at the tickets, ask the Product Owner: "What is the single most important outcome we're trying to achieve for the customer this Sprint?" or "If we complete these top items, what value will be delivered?" Second, based on the answer, propose a draft Sprint Goal. For example, "It sounds like we're trying to improve user retention. How about a goal like: 'Reduce user churn by 5% by implementing the new onboarding tutorial'?" Third, use the proposed goal to focus the conversation and negotiate scope. Ask, "Given this goal, does ticket X still make sense for this Sprint, or should we pull in ticket Y instead?"

COMMON WRONG ANSWERS: A major red flag is passivity or abdication of responsibility, such as saying, "I'd wait for the Scrum Master to intervene." This shows a lack of ownership. Another is being overly dogmatic or confrontational, like stating, "The Scrum Guide says we need a goal, so we can't start." This creates conflict instead of collaboration. The worst answer is to ignore the problem entirely and just start estimating the list of items, which demonstrates a fundamental misunderstanding of why a Sprint Goal exists: to provide focus and flexibility.

LIKELY FOLLOW-UPS: Expect questions that probe for nuance. "What if the Product Owner insists that all the items are P0 and there is no single theme?" (Your answer should focus on time-boxing the discussion and perhaps picking a smaller, achievable goal for a subset of the work). Or, "What if the rest of the team just wants to start coding?" (Your answer should be about influencing your peers by explaining the 'why' behind the goal—it protects the team from scope creep and provides clarity).

ONE CONCRETE EXAMPLE: "In a past role, our PO brought 10 tickets to planning, all marked 'highest priority.' They related to bug fixes, a new reporting feature, and a UI tweak. I asked what would happen if we only finished the top three. The PO explained they were all related to a recent enterprise customer complaint. I proposed the goal: 'Resolve the critical issues reported by Customer X to retain their business.' We then immediately re-prioritized the backlog to pull in only the tickets relevant to that customer, and we deferred the unrelated UI tweak. This gave us a clear 'why' for the Sprint and helped us say 'no' to other requests that came up mid-sprint."