Your development team just completed their best sprint planning session ever. Stories are well-defined, estimates are confident, dependencies are mapped, and everyone’s excited about the sprint goal. Two weeks later, you’ve delivered 40% of your commitments.
What happened? The same thing that happens to 90% of development teams: unplanned work devoured your capacity while everyone was focused on planned work.
But here’s what most CTOs don’t realize – unplanned work isn’t the enemy of predictable delivery. Poor unplanned work management is.
The Manufacturing Reality Check
In manufacturing, unplanned work is called “machine downtime” and it’s measured religiously. A factory running at 85% uptime is considered excellent. A factory that doesn’t measure downtime at all will fail.
Software development teams routinely ignore their equivalent of machine downtime, then wonder why they can’t deliver predictably. They plan sprints assuming 100% capacity utilization, which is like a factory assuming zero machine breakdowns.
The solution isn’t eliminating unplanned work – it’s systematically managing it.
The Four Categories of Unplanned Work
Category 1: Production Issues
- Critical bugs requiring immediate fixes
- Performance problems affecting users
- Security vulnerabilities needing patches
- Infrastructure failures demanding attention
Category 2: Knowledge Work
- Questions from other teams about your systems
- Code reviews for other team members
- Architecture decisions requiring your input
- Mentoring and training responsibilities
Category 3: Process Overhead
- Sprint ceremonies running longer than planned
- Hiring activities (interviews, onboarding)
- Administrative tasks and reporting
- Tool problems and environment issues
Category 4: Life!
The Murphy’s law bag of things….
- Unplanned sick leave
- Construction work in the adjacent building left our building without internet!
- Power outages or infrastructure failures – The data center cooling system fails during a heatwave, or the office loses power during your most critical sprint week
- Key team member suddenly leaves
Why Traditional Approaches Fail
The following are three typical policies that managers tend to put in place in order to deal with unplanned work that does not fully address its nature, and end up adding complexity to the development process.
The Reactive Approach: Deal with unplanned work as it arrives, stealing time from planned work.
→ Result: Constant context switching, incomplete stories, demoralized teams.
The Protective Approach: Try to prevent all unplanned work through better planning.
→Result: Rigid processes that break when reality intervenes, frustrated stakeholders.
The Buffer Approach: Add 20% buffer time to all estimates.
→ Result: Inflated timelines that still get consumed by unplanned work, loss of stakeholder confidence.
The Separate Capacity Strategy
Here’s the approach I use with CTOs who need predictable delivery: treat unplanned work as a separate capacity pool with its own allocation and measurement.
Step 1: Measure Your Unplanned Work
Track unplanned work for 4 sprints. Categorise it by type. Measure the capacity it consumes.
Step 2: Allocate Dedicated Capacity
Decide a percentage of your team’s capacity that you want to protect for unplanned work. For instance, if you measured unplanned work at 30%, then decide what exposure you are happy to take. Full protection would mean allocating more than 30% of your sprint capacity to unplanned work, anything below 30% would be accepting a certain degree of risk.
Step 3: Create Unplanned Work Protocols
Some things to consider:
- – Triage system for categorizing incoming unplanned work.
- – Escalation procedures for capacity overruns (sometimes, i will overrun your protection, what do you do?)
- – Communication protocols for stakeholders.
Real-World Implementation: The Series A Transformation
I worked with a Series A e-commerce CTO whose team had a 9-month streak of missing sprint commitments. Their velocity was good, their team was skilled, but predictability was zero.
The Diagnosis: Unplanned work was consuming 40% of capacity, but they were planning sprints as if they had 100% available.
The Implementation:
- – Sprint 1-2: Measurement phase – tracked all unplanned work
- – Sprint 3: Allocated 15% capacity to unplanned work pool
- – Sprint 4: Refined allocation based on data (increased to 30%)
- – Sprint 5+: Consistent delivery with systematic unplanned work management
Results after 12 weeks:
- – Sprint commitment delivery rate: 38% → 82%
- – Stakeholder confidence in delivery dates: Dramatically improved
- – Developer stress levels: Significantly reduced
- – Business impact: Features delivered on predictable schedules
The Strategic Advantage
Teams that master unplanned work management gain a massive competitive advantage: predictable delivery in an unpredictable environment.
While competitors struggle with constant fire-fighting and missed commitments, your team delivers consistently because you’ve systematically accounted for the reality of software development.
Your stakeholders trust your commitments because your commitments are realistic. Your team operates with confidence because they’re not constantly failing against impossible standards. Your business makes better strategic decisions because development timelines are reliable.
Parting thoughts
The ultimate goal isn’t just managing unplanned work – it’s building development processes that get stronger from unplanned work. When production issues improve your monitoring systems, when scope changes improve your requirements processes, when knowledge work builds team expertise – that’s when unplanned work becomes a strategic advantage rather than a tactical problem.
—
I work with CTOs and development teams helping them unlock productivity without following rigid methodologies. My approach adapts to your context because every team’s leverage points are different. Drop me a line and let’s start the journey together.
Discover more from The Software Coach
Subscribe to get the latest posts sent to your email.
