What options exist when a story is too large for one sprint?

What's really being asked

This question checks whether you understand story splitting as the primary response to oversized backlog items and whether you can distinguish vertical slices from architectural decomposition. The interviewer is looking for alignment with the idea that small user stories enable frequent value delivery and high-quality feedback, not just work breakdown for developer convenience.

The full answer

First, the team should discuss splitting the story into smaller vertical slices that each represent a complete change in system behavior from a user perspective. Second, they should evaluate those splits against the INVEST criteria to ensure each piece is independently valuable and small enough for the sprint. Third, the team must avoid splits that look like tasks or architectural components, because those defer user value and integration feedback until the end of the work. The central trade-off is between the discipline required to find true vertical slices and the risk of hiding complexity in horizontal layers that feel easier to plan but fail to deliver usable increments.

The mistakes people make

A red flag is proposing to split by architectural layer, such as separate database and UI stories, which the guide explicitly warns against because these look like tasks rather than user stories and prevent the team from getting early value and feedback. Another mistake is treating the large story as indivisible and simply accepting it, which breaks the ability to work from a prioritized backlog of small stories. Suggesting the team subdivide into developer tasks without delivering end-to-end behavior is also wrong, as it misses the point of vertical slicing.

What usually comes next

An interviewer might ask how to evaluate whether a split is good, which should lead to INVEST and the story splitting flowchart. They may ask for a concrete example of slicing a feature vertically rather than horizontally. They could also ask why architectural splits feel intuitive but fail, probing your ability to coach a team away from component-based thinking.

A concrete example

Consider a large story around building a user registration capability. A horizontal decomposition would create one piece for the database schema and another for the frontend form, meaning no user can actually register until everything is integrated. A vertical slice would deliver a first thin version where a user can register with just an email and password, providing immediate feedback and a working increment. Each subsequent slice can add validation, profile fields, or other rules, but every slice remains a complete user story that delivers value.