How should the team handle an oversized user story in Sprint Planning?

WHAT THIS TESTS: This question tests whether you treat the Sprint Goal as the primary commitment rather than a pile of stories, and whether you know how to decompose work vertically without destroying value. Senior candidates should demonstrate that they understand story splitting as a collaborative negotiation with the Product Owner, not just a technical task breakdown. The interviewer is listening for ownership of the planning process and a bias toward finishing valuable increments instead of starting large, risky items.

A GOOD ANSWER COVERS: A strong answer hits four things in order. First, stop and flag the mismatch immediately during Sprint Planning rather than hoping for the best. Second, collaborate with the Product Owner to split the story vertically into thin, end-to-end slices that each deliver user value and meet the INVEST criteria, ensuring the highest-value slice can fit inside the sprint. Third, if the split is still tight, propose swarming or pairing on that single slice so the team finishes it completely rather than leaving multiple stories half-done. Fourth, renegotiate the forecast with the Product Owner, moving excess scope to the Product Backlog and protecting the Sprint Goal from overload.

COMMON WRONG ANSWERS: Red flags include suggesting overtime or weekend work to force the original estimate, which violates sustainable pace. Another failure mode is horizontal splitting, such as breaking the story into a database layer task, an API task, and a UI task, because that prevents integration and demoable value until the very end. Assigning the story sequentially to multiple developers across sprints is also wrong, as it hides work-in-progress and breaks accountability. Finally, saying the team should just try harder or ignore the sizing error signals a lack of empirical process control.

LIKELY FOLLOW-UPS: The interviewer may ask how you would split a specific example like a checkout flow, so be ready to describe vertical slices such as happy-path payment, guest checkout, and error handling. They might also probe whether the team should change their Definition of Ready, or how to handle a Product Owner who refuses to split a story. Another common follow-up is how swarming affects individual accountability or how you would track progress on a split story in the backlog.

ONE CONCRETE EXAMPLE: Imagine a story to build a subscription dashboard estimated at thirteen points. The team realizes one developer cannot finish it in two weeks. During planning, they work with the Product Owner to slice it into three stories: view active subscriptions, filter by date range, and export to CSV. The team pulls only the view story into the sprint, pairs two developers on it for three days, and delivers a working increment by day four. The Product Owner accepts the forecast update, and the filter and export stories return to the top of the Product Backlog for the next sprint.