How do you handle a story that's too large for a sprint?
Tests your ability to apply agile principles pragmatically. A great answer prioritizes the Sprint Goal, collaborates with the PO to vertically slice the story into smaller valuable pieces, and then re-plans the sprint backlog.
What's really being asked
This question tests your ability to facilitate collaborative problem-solving and your understanding of vertical slicing. It's not about memorizing Scrum rules, but about applying agile principles to deliver incremental value when plans change. The interviewer wants to see if you prioritize the Sprint Goal over individual stories and if you can guide a team to a practical solution without sacrificing quality or creating technical debt.
The full answer
A good answer hits four points in order. First, immediately raise the issue with the whole team, including the Product Owner (PO). The goal is transparency, not blame. Second, re-center the discussion on the Sprint Goal—is this specific story essential to achieving it, or can a smaller part of it suffice? Third, lead the effort to split the story vertically. This means breaking it down by user workflow, business rules, or acceptance criteria, not by technical layers. Each resulting story should be a testable, valuable increment. Fourth, once split, the team and PO re-evaluate the sprint backlog, pulling in the highest-priority new stories that fit the team's capacity and still support the Sprint Goal.
The mistakes people make
The most common red flag is suggesting a horizontal (technical) split, like creating a "backend story" and a "frontend story." This delivers zero user value until both are complete and creates a dependency that complicates future sprints. Other poor answers include: suggesting the team works overtime (unsustainable), carrying the incomplete story over to the next sprint (violates the "Done" increment principle and inflates velocity), or simply assigning multiple developers to the oversized story (which creates coordination overhead without solving the size problem).
What usually comes next
Be ready for "How would you prevent this from happening in future sprints?" (Answer: Propose more rigorous backlog refinement sessions, introduce the INVEST criteria for user stories, and use story mapping to visualize dependencies and size earlier). Another follow-up is "What if the story is truly monolithic and cannot be split?" (Answer: This challenges the team and PO to question if it's truly one story or if the underlying user need can be met differently. It may require a "spike" or research story to de-risk it before it can be properly estimated and split).
A concrete example
A large story might be: "As a shopper, I can pay for my order." A vertical split would be creating smaller, independent stories like: 1. "Pay with Visa credit card (no validation)." 2. "Add validation for Visa card numbers." 3. "Add support for Mastercard." The first story delivers end-to-end value, even if minimal. A horizontal split would be "Build payment API" and "Build payment UI," which is incorrect because neither delivers value on its own.
Interview question
A team realizes a story is too large to complete mid-sprint. What is the most effective way to handle this while upholding agile principles?
- a.Keep the story as is and carry over any unfinished work to the next sprint, documenting the partial progress.
- b.Split the story horizontally by technical layers, creating separate 'backend' and 'frontend' stories for different sprints.
- c.Split the story vertically into smaller, testable increments of user value and re-prioritize the sprint with the Product Owner.Correct
- d.Assign more developers to the story to increase the workforce and meet the original commitment.
Why? this is the answer
Vertical slicing ensures a valuable, 'Done' increment is delivered, aligning with the Sprint Goal. Splitting horizontally by technical layers is a common anti-pattern that creates dependencies and delivers no user value until all parts are complete.
Just read this? Test yourself on what you have been reading.
Read the original → agilealliance.org
- #agile
- #scrum
- #sprint planning
- #estimation
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on agile — each one lists the topics its interview covers.
See open roles