I think we software developers massively underestimate how much unplanned work we do every sprint
Almost everyday starts with a rough idea of what we're going to get done.
Then reality happens.
Standup changes priorities.
Someone Slacks you for help.
A production issue pops up.
A PR review takes longer than expected.
You discover the ticket is twice as complicated as you thought.
By the end of the day, you realize you spent hours on things you never planned to do.
I'm starting to think developer productivity isn't about executing the perfect plan.
It's about understanding why the plan changed.
Was it legitimate interruptions?
Poor estimation?
Context switching?
Helping teammates?
Urgent work?
I'm curious how this looks for everyone else.
When you finish your day, which feels most accurate?
"I got through most of what I planned."
"Half my day disappeared into unexpected work."
"I honestly couldn't tell you where the time went."
And if you've found a good way to understand where your day actually went (without manually tracking everything), I'd love to hear your thoughts.
Replies
I’d say “half my day disappeared into unexpected work” is the closest.
A lot of it is legitimate work, but it usually doesn’t show up clearly in the original sprint plan. PR reviews, debugging, helping someone unblock, investigating a weird issue, or realizing a ticket has hidden complexity can easily consume hours.
The problem is that most tools are better at showing what we planned than what actually happened. So at the end of the day, it feels like low productivity even when the work was useful.
What helps is reviewing the day in terms of categories instead of just tickets: planned work, interruptions, reviews, debugging, support, and context switching. That makes it easier to see whether the issue was poor estimation, too much reactive work, or just normal engineering reality.
@akarsh_hegde yeah, same. The hardest part is that the unexpected work is still real work, but it gets treated like noise because it was not in the sprint plan.
Most teams plan sprints like developers will only do ticket work, but that is rarely how the day actually goes.
The unplanned work is usually not wasted time. It is code reviews, production issues, clarifying messy requirements, helping teammates, or finding out a “small” ticket was never small. The problem is that it stays outside the plan, so it looks like productivity dropped when the team was actually absorbing real engineering work.
I think the useful question is not just “where did the time go?”, but “which unplanned work keeps repeating?” That is where you start seeing patterns worth fixing.
@prateekbhoge Yep. Once the same “unplanned” work shows up every sprint, it is not really unplanned anymore, it is just untracked capacity.
The repeated stuff is where the signal is. If reviews, production issues, or requirement clarifications keep eating the sprint, the fix is not telling devs to focus harder, it is making that work visible in planning.