Tactical Work Shedding - How to Plan for the Plan to Fail
Every sprint plan will go sideways. Every project timeline will hit unexpected problems. This isn't pessimism. It's pattern recognition from years of leading engineering teams through hundreds of delivery cycles.
The data backs this up: according to PMI's 2018 Pulse of the Profession research, 52% of projects experience scope creep or uncontrolled changes. Even among high-performing agile teams, research shows that maintaining sprint completion rates above 85% requires actively managing inevitable changes throughout the sprint.
The question isn't whether your estimates will be wrong. The question is: have you already decided what to cut when they are?
I call this approach Tactical Work Shedding, and it's a reliable practice I've used as a tech lead collaborating with product managers on sprint planning and feature delivery.
The Two Day Rule
Any project that takes more than two days of work carries inherent risk. Not because two days is magic, but because anything beyond that scope has enough surface area for unknowns to surface, dependencies to shift, and assumptions to break.
We like to believe that with enough planning, enough story points, enough refinement sessions, we'll finally nail the estimate. But after leading teams through countless sprints, I've accepted a different truth: planning won't be perfect, so let's plan for that imperfection.
This is where understanding risk prioritization becomes critical. The uncertainties on multi-day projects aren't random—they follow predictable patterns. Knowing how to surface and eliminate risks early transforms sprint planning from a guessing game into structured risk management.
The Unofficial Conversation
Here's how Tactical Work Shedding works in practice.
Once the team has finished planning, once we've estimated the work and committed to the sprint, I take an unofficial sidebar with the product manager. We drop the formal hats for a moment. The conversation goes something like this:
"We've committed to everything on the board. We're going to work hard to deliver all of it. But when something goes sideways (and something always does), what should we cut first?"
This isn't about padding estimates or under-committing. Everything we've planned stays in the official plan. This is a parallel conversation about prioritization under pressure.
The key insight: it's far easier to negotiate these tradeoffs before the crisis than during it.
Why Upfront Negotiation Matters
When you're three days from a deadline and suddenly realize you can't deliver everything, negotiations get messy. Stakes are higher. Emotions run hotter. Everyone scrambles.
But there's an even more practical reason to have this conversation early: architecture and execution order.
If you haven't decided what's sheddable upfront, you can't sequence your work to protect the critical path. You might spend the first half of your sprint building features that you'd cut in hindsight. Now you've invested the time, and you can't get it back. You're forced to complete everything because the work you would have cut is already half-done.
When you know the shedding priority before you start, you can structure the work so the most critical pieces get built first. The optional pieces come last. For example: build the core API functionality first, then add the admin dashboard polish at the end. Implement the primary user workflow before the secondary edge cases. Get the data pipeline working before building the fancy visualization layer. If time runs out, you've already delivered the core value.
This approach aligns with how successful teams handle burndown charts—by understanding that scope injection happens, and having a plan for which work absorbs that impact.
The Trust Requirement
This strategy only works with a good working relationship between tech lead and PM. It requires mutual understanding that both parties want the project to succeed, both are committed to delivering everything planned, and both recognize that software estimates are genuinely hard.
It's not cynicism about the team's abilities. It's realism about the nature of building software.
The PM needs to trust that engineering isn't sandbagging. Engineering needs to trust that the PM won't use the shedding conversation as evidence of weak commitment. Both sides need to approach this as collaborative risk management, not adversarial negotiation.
Why I Don't Share This With Engineers
Here's the part that might be controversial: I typically don't share the specific shedding agreements with the engineers on my team, though I do communicate that we've sequenced work by priority.
The team committed to delivering a certain scope. I want them focused on that commitment. Introducing "well, if things go wrong, we can cut X" undermines their sense of ownership. It creates an easy out that might get invoked too quickly.
This approach requires careful balance. Research on agile team dynamics shows that psychological safety is critical for high performance, but also that teams hearing "commitment" as "miss that and you're in trouble" leads to sandbagging and decreased productivity. The key is maintaining full commitment to delivery while the tech lead privately maintains the contingency plan.
As the tech lead, my job is to organize and sequence the work in a way that enables shedding if necessary. The team focuses on execution. I focus on the contingency structure.
If we do need to shed scope mid-sprint, I work with the PM to make that call and communicate it to the team as a deliberate reprioritization, not as invoking a pre-planned escape hatch.
What Makes Something Sheddable
Not everything can be cut. When having the shedding conversation, I look for:
Work that delivers incremental value rather than core functionality. The extra polish, the secondary use case, the nice-to-have integration. These are legitimate scope items, not padding, but they're not the primary value delivery.
Features with isolated dependencies. If cutting something would require ripping out other completed work, it's not a good shedding candidate. The best candidates are cleanly separable.
Items where the customer would prefer the core feature now rather than the full feature later. This requires understanding the actual business priority, not just the backlog order. As with any meaningful product work, the root of good shedding decisions lives upstream in how your team thinks about requirements, architecture, and the real constraints shaping product development.
The Public vs. Private Plan
To be clear: all public commitments, all documentation, all standups reflect the full scope we planned. Tactical Work Shedding is an unofficial agreement between tech lead and PM.
This isn't about deceiving the team or stakeholders. It's about having a mature, realistic conversation between the people responsible for delivery and prioritization. The same way a pilot files a flight plan but also knows the diversion airports, we plan for success while preparing for contingencies.
The Results
When practiced consistently, Tactical Work Shedding produces teams that deliver valuable software on time, even when the full scope gets compressed. Instead of the familiar death march to hit an unrealistic deadline, you get controlled descoping that protects the most important outcomes.
The PM gets predictable delivery of core value. Engineering gets sustainable pace without heroics. Stakeholders get working software instead of excuses.
It requires trust, honest relationships, and accepting that estimates will be wrong. But once you build that foundation, it transforms how your team handles the inevitable uncertainty of software development.
The next time you're planning a sprint or kicking off a project, try the sidebar conversation. Figure out what you'd cut first. Then sequence your work to make that cut possible when you need it.
You probably won't need it. But when you do, you'll be ready.
Related Content
