Has anyone dealt with teams refusing to break down large stories (13s, 21s)? What helped?
Hi all,
I’m currently coaching a team that regularly carries 13 and 21-point stories into our sprints—and they’re resisting efforts to break them down further. These stories often stretch across multiple days (sometimes the entire sprint), creating bottlenecks for QA and affecting our deployment rhythm.
From a delivery perspective, I’m concerned about the impact on cycle time, feedback loops, and overall predictability. While I’ve brought this up during planning and retros, the team’s mindset tends to be, “It’ll get done,” or “We don’t see a reason to split it.” I’ve tried nudging toward smaller vertical slices, but it hasn’t stuck yet.
I’m curious—has anyone else faced this kind of resistance?
- What strategies helped shift the mindset?
- Did any particular metric, conversation, or practice help the team recognize the value of breaking things down?
I’m not looking for perfection—just meaningful progress that helps improve flow and reduces last-minute testing crunches.
Appreciate any insights or experiences you’re willing to share.
I've worked with some teams who feel this way. One team (wrongly) associated story size with functional completeness and value. Another team felt splitting stories created busy work for the team and didn't see the point.
You might look for coachable moments and leverage the Sprint Retrospective to highlight when one of the larger stories led to a missed Sprint goal, overtime, or spilled over to the next Sprint.
Another thing you could try. Instead of focusing the discussion on spiliiting PBIs into smaller story points, step into the teaching stance to have a conversation about the cost and risk of delayed feedback during the Sprint. Cycle time is a flow metric a Scrum team can leverage. If the average PBI doesn't finish until the end of the Sprint, that seems risky to me.
Try starting with just one large story and have them break it down in refinement, and see if there's something they can learn from that.
creating bottlenecks for QA and affecting our deployment rhythm.
You see this as a problem, but do they? What are the consequences for them? How do they feel the results of this compromised ability to provide value?
I've worked with teams where a 13 was the smallest value they would assign to a story. Since story points have no real value, I saw no problem with it. As long as the entire team understood that 13 was the smallest value and that all stories were being judged in the same way, why would that be a problem? If you try to force them to use smaller numbers or break things down further, it will only cause frustration and resentment. Story points and user stories are not part of the Scrum framework. They are tools that can be used to help promote understanding. But often they are the source of misunderstanding and angst. Ask the team if the story points are actually any use to them. If not, then quit using them and have them find something that they feel is better.