A story is too large for one sprint. What are your options?

What's really being asked

This question tests your senior-level pragmatism and focus on delivering value, not just completing tasks. The interviewer wants to see if you can facilitate a discussion about trade-offs and risk, rather than just dictating a single solution like "split the story." It assesses your understanding of core agile principles like incremental delivery and sustainable pace.

The full answer

A strong answer outlines a clear, collaborative process. First, re-validate priority with the Product Owner. Is this feature truly the most valuable thing to work on right now, or can it be deferred in favor of smaller, high-value stories? Second, if it must be tackled, the primary option is to split the story. The key is to advocate for a VERTICAL slice—a thin, end-to-end piece of functionality that is demonstrable and provides real user value. Third, mention a few splitting patterns, like splitting by workflow steps, business rules, or happy path vs. error handling. Finally, articulate the trade-offs of each option (deferring vs. splitting).

The mistakes people make

The biggest red flag is suggesting a HORIZONTAL split, like creating separate stories for the frontend, backend, and database work. This delivers zero user value until all parts are integrated, which defeats the purpose of a sprint. Another red flag is suggesting the team work overtime or extend the sprint; this violates the principle of a sustainable pace. Simply saying "we need a spike" without first attempting to split is also a weak answer; spikes are for uncertainty in the how, not just size.

What usually comes next

Expect questions like, "What if the Product Owner insists the whole feature must be released at once?" or "How do you handle a split where the first slice is purely technical and has no UI?" For the first, it's a coaching opportunity about risk. For the second, you should explain that while not ideal, a small enabling slice can be acceptable if it unblocks significant future value and is kept minimal.

A concrete example

A story like "As a user, I can pay with a credit card" is too large. A horizontal split would be "Build CC form," "Build API client," "Update DB schema." This is wrong. A good vertical split is "As a user, I can pay with a Visa card (happy path only)." This delivers a complete, testable, and valuable piece of functionality. Subsequent stories can add other card types, error handling, or fraud detection.