The team estimated story points and committed to a sprint goal.
They planned every hour of the coming weeks.
The senior developer asked, “What happens to the time you didn’t plan?”
And, “When you commit to the future, what do you assume about the present?”
What This Means for Your Practice
Sprint planning represents one of software development’s essential tensions: the need to coordinate and commit versus the reality that uncertainty cannot be planned away. We estimate story points, break down tasks, and commit to deliverables because teams need direction and stakeholders need predictability. Yet something subtle occurs in this process.
When we plan every hour of the coming weeks, we’re not just organizing work. We’re making assumptions about what won’t change, what won’t break, what won’t be discovered, and what won’t become suddenly urgent. We assume the production environment will remain stable. We assume requirements won’t shift. We assume no one will get sick, no critical bugs will surface, no dependencies will fail. Most significantly, we assume our understanding of the work is complete before we’ve actually done it.
The unplanned time doesn’t disappear because we didn’t account for it. It simply arrives unannounced, disguised as an emergency, a distraction, or a delay. The question “what happens to the time you didn’t plan?” invites us to notice how much of our actual work lives in these gaps. The colleague who needs help debugging. The architecture conversation that reveals a hidden complexity. The moment of insight that comes only from actually building the thing, not from estimating it.
Consider what you assume about the present when you commit to the future. You assume your current understanding is sufficient. You assume the codebase will behave as documented. You assume the tools will work as expected. These aren’t necessarily wrong assumptions, but they’re still assumptions. And every sprint that goes according to plan does so partly because the team quietly absorbed the chaos that wasn’t planned for.
The practice here isn’t to stop planning. Teams need coordination, and stakeholders need reasonable expectations. Rather, it’s to hold plans more lightly, to build in acknowledgment that the unplannable is not exceptional but fundamental. It’s to recognize that “commitment” in the face of uncertainty might mean something different than we thought: not rigid adherence to a plan, but steady presence with whatever emerges.
What would change if your sprint planning included explicit time for what you cannot predict? Not buffer time or contingency, but a genuine acknowledgment that discovery, adaptation, and emergence are part of the work itself, not deviations from it?