May 19, 2026
6 min read
Data-driven sprint planning
How to Plan Sprints with Uncertainty
A practical guide to planning sprints when work is uncertain, risky, or not fully understood yet.
Start by making uncertainty visible
Planning sprints with uncertainty does not mean pretending the team knows everything before work begins.
It means making uncertainty visible enough that the team can decide whether to refine, split, spike, reduce scope, or commit with a clear risk attached.
Planning with uncertainty
Make uncertainty visible first, then shape the sprint around what the team actually knows.
Uncertainty visible
The team plans better when unknowns are named before the sprint starts.
Known core
Identify the work the team understands well enough to trust.
Conditional edge
Separate work that depends on fragile assumptions.
Learning gaps
Some work may need clarification before it belongs in the sprint.
Safer plan
A healthier sprint plan distinguishes between likely delivery and uncertain edges.
Separate uncertainty from effort
A story can feel large because it contains a lot of work, but it can also feel large because the team does not understand it well enough yet.
Those are different problems. More effort may need a bigger estimate. More uncertainty may need refinement, a smaller slice, or a spike before commitment.
Look for the source of uncertainty
Uncertainty is easier to handle when the team can name what kind it is. The plan changes depending on whether the unknown is product scope, technical approach, dependency, acceptance criteria, or delivery capacity.
- Scope uncertainty: what is actually included?
- Technical uncertainty: how will the solution work?
- Dependency uncertainty: who or what are we waiting on?
- Completion uncertainty: what will count as done?
Do not hide uncertainty inside a bigger estimate
Teams often respond to uncertainty by giving the story a larger estimate and moving on.
Sometimes that is honest. But if nobody can explain what is driving the size, the larger number may just be uncertainty wearing an effort costume.
Use spikes when learning is the real work
If the team cannot estimate because it does not yet understand the technical path, dependency, or feasibility, a spike may be more honest than another round of guessing.
A good spike should answer a specific question that makes the next planning decision easier.
Keep risky work from filling the whole sprint
A sprint with one uncertain item may still be manageable. A sprint full of uncertain items becomes fragile quickly.
Healthy planning usually mixes clearer work with riskier work instead of building the entire commitment around unresolved unknowns.
Use capacity to create room for uncertainty
Uncertainty consumes capacity because the team spends time discovering, coordinating, reworking, and clarifying.
If a sprint contains meaningful uncertainty, the team should avoid loading capacity to the edge and then acting surprised when reality takes space.
Where to go next
If your team keeps discovering uncertainty after commitment, start with the estimator and capacity tool together.
That is where the team can make uncertainty visible before deciding how much work honestly fits.
TL;DR
- Planning with uncertainty means naming the risk before commitment.
- Uncertainty is not the same thing as effort.
- Some uncertain work needs refinement, splitting, or a spike before planning.
- Uncertainty becomes easier to plan around when the team separates what feels likely from what still needs more evidence.