Handling a user story too large for a sprint

WHAT THIS TESTS: This question tests your understanding of core Agile principles beyond just Scrum ceremony. The interviewer is looking for your ability to solve problems pragmatically within the framework. They want to see if you prioritize delivering incremental user value (vertical slicing) over simply dividing up technical tasks (horizontal slicing). It also tests your collaboration and negotiation skills with the Product Owner and the team.

A GOOD ANSWER COVERS: A strong answer has four parts. First, immediately raise the issue with the Product Owner and the rest of the team during Sprint Planning. Re-center the conversation on the Sprint Goal. Second, propose splitting the story. The key is to split it vertically, creating smaller, end-to-end testable stories that each deliver a sliver of user value. Third, if vertical splitting isn't possible, negotiate scope with the PO. This might mean deferring the large story and pulling in smaller stories that still support the Sprint Goal. Fourth, explicitly mention avoiding horizontal splits (e.g., by technical layer) as an anti-pattern.

COMMON WRONG ANSWERS: A major red flag is suggesting a horizontal split, like "one person does the frontend while another does the backend." This creates dependencies, delays integration, and delivers zero user value within the sprint. Another poor answer is to simply start working on the large story and accept that it will "spill over," which undermines the purpose of sprint commitments and makes velocity unpredictable. Also, suggesting multiple developers swarm one unsplit story is inefficient and points to a misunderstanding of the problem.

LIKELY FOLLOW-UPS: Be ready for "Can you give me a concrete example of how you'd split a story?" or "What if the Product Owner insists the whole story is 'all or nothing'?" They might also ask, "How would you prevent this from happening in the first place?" (Answer: better backlog refinement and story mapping sessions).

ONE CONCRETE EXAMPLE: For a story like "As a user, I want to pay for my order with a credit card," which is huge, don't split it into a UI story and an API story. Instead, split it vertically. Slice 1 could be "Process a valid Visa card payment (happy path only)." Slice 2 could be "Display a generic error for any failed payment." Slice 3 could be "Add support for Mastercard." Each slice is a complete, testable piece of functionality that delivers value.