Your dev team plans a two-week sprint. Fourteen tasks go in. Nine come out done. The other five quietly roll into the next sprint, and nobody's surprised anymore.
That's sprint rollover. And it's usually not a sign your developers are slow. It's a sign of sprint planning mistakes made before anyone wrote a line of code.
The biggest one? Dependencies. Easy Agile's State of Team Alignment 2026 report, which surveyed 419 engineers, PMs and project managers, found dependency delays cause 35.6% of sprint rollover. More than a third of slipped work, stuck waiting on someone or something else.
Below, we break down the seven sprint planning mistakes we see most often, what each one costs, and how to fix them. Written for founders and team leads, not just Scrum experts.
What sprint rollover is and why it matters
A sprint is a fixed block of time, usually one or two weeks, where a team commits to finishing a set of work. Rollover is work that was committed but didn't get done, so it moves to the next sprint.
Is some sprint rollover normal?
A little, yes. Estimates are never perfect. But if a quarter or more of every sprint rolls over, sprint after sprint, your planning is broken. Roadmap dates stop meaning anything, and the team stops trusting its own commitments.
Why should a business owner care?
Because rollover compounds. Every slipped task pushes a feature launch, a client deliverable or a sales promise. And the team feels busy the whole time, which makes the problem easy to miss.
Mistake 1: Ignoring dependencies until mid-sprint
A dependency is anything a task needs before it can be finished. An API from another team. Designs from a freelancer. Client approval. A vendor's access credentials.
The mistake is pulling a task into the sprint without checking whether that thing will arrive in time. Then on day six, the developer is blocked. They switch to something else, lose context, and the task rolls over.
The fix: before planning, list every dependency for each candidate task. If it isn't confirmed ready, or doesn't have a firm date inside the sprint, the task waits. Simple rule. Saves a lot of rollover.
Mistake 2: Planning at 100% capacity
Five developers times ten working days doesn't equal fifty days of feature work. People take leave. Bugs come in. Meetings happen. Code reviews take time.
Teams that plan to full capacity have zero buffer. One surprise and the sprint breaks. And there's always a surprise.
The fix: plan to around 70 to 80% of real capacity, after subtracting leave and holidays. There's a worked example further down.
Mistake 3: Estimating only in hours
The same report found 54.6% of teams estimate in hours or days. The problem is that hours don't capture complexity or uncertainty. "Four hours" for a task nobody has done before is a guess wearing a number.
The fix: estimate relative size, using story points or simple sizes like S, M and L, and flag anything with high uncertainty. Better still, estimate together. Only 31% of teams use collaborative estimation, and it's one of the fastest ways to catch a task one person thinks is easy and another knows isn't.
Mistake 4: Pulling in work nobody understands yet
If the team is still asking "what does this actually mean?" during sprint planning, the task isn't ready. Vague tasks expand. They turn into three tasks halfway through the sprint.
The fix: run backlog refinement before planning. Every task entering a sprint should have clear acceptance criteria: what "done" looks like, in plain words.
Mistake 5: Changing scope mid-sprint
This one is often the founder's mistake. A client calls. A competitor launches something. And a new "urgent" task drops into the sprint on day four.
Once in a while, fine. Every sprint, and the plan stops meaning anything. The team learns that commitments are optional.
The fix: if something urgent comes in, something of equal size comes out. Make the trade-off visible. Most "urgent" requests can wait one week.
Mistake 6: Running retros that change nothing
A retrospective is the meeting at the end of a sprint where the team discusses what went wrong. Easy Agile found 69% of teams implement less than 60% of their retro actions. So the same problems show up, sprint after sprint.
The fix: pick one or two retro actions, give each an owner, and add them to the next sprint as real tasks. Fewer actions, actually done.
Mistake 7: Planning in spreadsheets, delivering somewhere else
The report found 58.5% of teams keep planning data in spreadsheets while the actual work lives in tools like Jira. So nobody can see velocity honestly, and every planning session starts from guesswork.
The fix: keep planning, estimates and delivery in one place. Whatever tool you use, the sprint plan should be the same thing the team works from every day.
Here's the summary.
How to run sprint planning that actually holds
Here's the sequence we recommend. It works for a team of three or thirty.
- Refine the backlog first. A day or two before planning, make sure the top tasks have clear acceptance criteria.
- Calculate real capacity. Count available days after leave and holidays, then plan to 70 to 80% of that.
- Check dependencies for every task. If a dependency isn't confirmed ready, the task waits.
- Estimate together. Use relative sizes and discuss any task where estimates differ widely.
- Set one sprint goal. A single sentence that explains why this sprint matters to the business.
- Add last sprint's retro actions. One or two, with owners, as real tasks.
How much work should a team commit to in a sprint?
As a rule of thumb, 70 to 80% of real available capacity. Then adjust based on what the team actually finished in the last three sprints. Past delivery is a better guide than optimism.
Here's how that capacity math works for a small team.
Story points or hours: which is better?
For deciding what goes into a sprint, relative sizing usually works better, because it captures complexity, not just time. Hours still help for capacity math and for small, well-understood tasks. Many teams use both: points for what goes in, hours for checking it fits.
How long should a sprint planning meeting take?
The Scrum Guide caps sprint planning at eight hours for a one-month sprint, and shorter sprints usually need less. For a two-week sprint, two to three hours is typical. If it runs much longer, the backlog probably wasn't refined beforehand.
What this looks like in practice
Take a typical case. A seven-person product team at a growing D2C brand in Mumbai, building their customer app in two-week sprints. Roughly a third of every sprint rolls over. The founder assumes the team is slow.
Look closer and the pattern is obvious. Half the rolled-over tasks were waiting on designs from an outside agency or payment gateway access from a vendor. The rest were urgent requests added mid-sprint.
Two changes fix most of it. A dependency check before every planning session, and a "one in, one out" rule for mid-sprint requests. Nobody works harder. The team just stops committing to work that was never going to finish.
Questions to ask your development team or agency
If you're a founder working with an in-house team or an outside partner, you don't need to run sprints yourself. But you should be able to ask:
- What's our average rollover, and what causes it?
- How do we check dependencies before committing?
- What capacity do we plan to?
- Which retro actions did we actually implement last month?
Clear answers mean the process is healthy. Vague answers mean it's worth a closer look. That applies to any team, including ours. When Nipralo takes on custom software and app builds, these are exactly the questions we expect clients to ask us. You can see the kind of products we deliver in our web and mobile app work.
The bottom line on sprint planning mistakes
Most sprint planning mistakes aren't about effort. They're about committing to work that isn't ready, isn't sized honestly, or depends on something nobody checked.
Fix dependencies first, since they drive more than a third of rollover. Then plan to real capacity, estimate together, and protect the sprint from mid-week surprises. Your team will ship more by committing to less.
If your product keeps slipping and you can't tell why, book a free 20-min call. We'll look at how your sprints are planned and tell you honestly where the time is going.
