A high-priority story is too large for one sprint. What are the options?

WHAT THIS TESTS: This question tests your focus on delivering user value over completing technical tasks. The interviewer wants to see if you default to creating a small, functional, end-to-end increment, even if it's not the full feature. It evaluates your understanding of vertical vs. horizontal slicing and your ability to lead a team discussion on scope, trade-offs, and negotiation with a Product Owner. A senior engineer should facilitate this, not just ask for smaller tickets.

A GOOD ANSWER COVERS: First, state the goal is to find a smaller, end-to-end 'vertical slice' that delivers demonstrable user value. This means it touches all necessary tech layers (UI, API, database) to be functional. Second, propose common splitting patterns to find that slice. You can split by workflow steps ('view report' now, 'export report' later), by business rules ('handle US orders' now, 'international orders' later), or by acceptance criteria (implement the most critical criterion first). Third, if splitting is difficult, suggest negotiating with the Product Owner to de-scope the original story to its minimum viable essence. Fourth, as a last resort, if a story is a true monolith, question its readiness. It may require a time-boxed 'spike' to de-risk unknowns or be deprioritized for smaller stories that can be completed.

COMMON WRONG ANSWERS: Suggesting a horizontal split is the biggest red flag. Answering with "Let's create a backend story for the API and a frontend story for the UI" delivers zero value in the sprint, prevents feedback, and violates the principle of a 'Done' increment. Another red flag is defaulting to a spike. A spike is for investigation, not for pushing implementation work to a future sprint. Finally, simply increasing the story point estimate and promising to work harder ignores team capacity and increases the risk of failure.

LIKELY FOLLOW-UPS: Expect follow-ups like: "What if the Product Owner insists the entire story must be done now?" which tests your negotiation skills. Or, "Give me a concrete example of a story and walk me through how you'd split it." Or, "How do you handle external dependencies that make the story too large?"

ONE CONCRETE EXAMPLE: Original Story: "As a shopper, I want to pay for my order using a credit card, PayPal, or Apple Pay." This is likely too large for a single two-week sprint. A bad split would be Story 1: 'Build payment APIs' and Story 2: 'Build payment UI'. A good vertical split would be Story 1: "As a shopper, I can pay for my order using a credit card." This is a complete, valuable feature. The team could deliver PayPal and Apple Pay in subsequent sprints, delivering value worth 90% of the revenue in the first sprint, instead of 0%.