Why your sprint plan keeps falling apart, and what to do about it.
- jimapodaca
- May 26
- 4 min read
Updated: Jun 3
You’ve got all the right pieces—smart people, clear goals, and even a delivery framework like Scrum. But somehow, your sprint plan still feels incomplete. Like a puzzle where the edges don’t quite fit… or critical pieces keep going missing.
If this sounds familiar, you’re not alone—and the problem isn’t your team.
It’s the system trying to hold everything together.
Last week, I ran a LinkedIn poll asking leaders and practitioners to identify the biggest delivery challenges their teams face. The top three answers weren’t surprising—but they were telling:
✅ 38%: Too much work in progress (WIP) / bottlenecks
✅ 31%: Stories carry over every sprint
✅ 31%: Changing priorities mid-sprint
These numbers speak to a deeper problem: It’s not your team that’s broken. It’s your system. And if you don’t fix the system, no amount of pushing, sprinting, or stand-ups will move the needle. In this article, I’ll break down each delivery challenge and share three best practices you can use to bring order to the chaos—without burning out your team.
1. Too Much WIP / Bottlenecks "It feels like we’re doing everything—and nothing is getting done."
When teams are drowning in WIP, they confuse activity for progress. The problem isn’t laziness. It’s a lack of constraint.
Best Practices:
Visualize the flow. Start by making WIP visible. Use a Kanban board with explicit WIP limits. When work piles up in "in progress" or "review" columns, that’s your bottleneck. Shine a light on it.
Enforce WIP limits. Set hard caps on how much work a person or team can have in flight. This forces focus. Multitasking is a myth—and context switching kills momentum. Allocate your teams velocity to account for impediments, and never schedule your sprint to full capacity. I like to schedule sprint capacity at 60% for new features and maintenance, 20% technical debt, and 20% impediments.
Swarm the stuck. When something’s stuck, pause new starts and swarm the issue. One client I worked with cut cycle time by 45% just by focusing on clearing the board, not starting the next thing.
At a fintech start-up, I coached teams that were juggling 15+ active stories per sprint. We implemented WIP limits and introduced a "Swarm & Finish Friday." Within 6 weeks, sprint completion jumped from 52% to 89%.
2. Story Carryover Every Sprint "We plan 12 stories. We deliver 7. The rest roll over. Every. Single. Time."
This kind of carryover is a morale killer. And more often than not, it signals poor slicing, overcommitment, or hidden work.
Best Practices:
Slice smaller. If your stories aren’t finishing in 3–5 days, they’re too big. Use vertical slicing to ensure each story delivers something usable—not just a piece of a piece. The goal with every sprint should be to deliver working tested software. Work that rolls over from sprint-to-sprint is often a sign of deeper issues, mainly poor requirements and poorly written user stories. Lack of user story best practices is a common culprit to user stories that persist from one sprint to the next.
Track velocity (but don’t worship it). Know how much your team can actually complete. Plan based on historical velocity, not optimism. One team I worked with consistently planned 30% over capacity—because they never adjusted. Team capacity should be adjusted to reflect the teams actual capacity, including time off, holidays, and team member availability.
Build in buffer. Leave 15% to 20% of sprint capacity uncommitted. This gives you room to absorb small changes without collapsing the whole sprint.
At a health-tech company I supported, we cut story size by half, focusing on user story best practices and committing to fewer stories per sprint. Story carryover dropped 70% within three sprints.
3. Changing Priorities Mid-Sprint "We planned the sprint on Monday. By Thursday, the priorities have changed. Again."
This one is brutal. It kills trust, motivation, and momentum. But here’s the hard truth: it’s often a symptom of leadership misalignment, not team failure.
Best Practices:
• Establish a sprint contract. Make it clear: Sprints are sacred. Outside requests go into the backlog unless it’s a true fire. This requires buy-in and support from leadership.
• Create a change path. If something must change mid-sprint, have a clear process. Who decides? What gets bumped? Transparency reduces chaos. Scrum roles and responsibilities are key to managing sprint chaos. Impediments should be negotiated between the Scrum Master and Product Owner. The number one goal of the Scrum Master is to shield the team from chaos and negotiate trade-offs with the Product Owner. If team capacity is set 20 story points for the sprint, and the product owner wants to add an additional 5 points to the sprint, then it is the Scrum Masters role to negotiate which 5 points of existing work needs to be swapped out for the 5 point impediment.
• Reinforce priorities in every planning session. Don’t assume alignment. Re-anchor to OKRs or quarterly priorities. At one client, we started each sprint planning by reviewing the top 3 company goals. Change requests dropped dramatically.
A media company I supported was getting whiplashed by leadership changes. We introduced a "change request channel" with a cost-of-change impact summary. Interruptions dropped by 60%.
Final Thoughts: Execution Is a System
You can have the best people and best intentions—but if your delivery system is broken, you’re going to feel stuck. Fix the system, and you free your team.
If your team is dealing with WIP overload, sprint chaos, or strategy that changes with the wind—you don’t need another tool. You need a reset. Let’s talk.
Book a free 30-minute Execution Audit. I’ll help you spot the breakdowns, clarify your strategy, and build a delivery system that actually delivers.
Take our Scrum Health Assessment to learn how your scrum team is performing.
Comments