If you’ve ever hit the last day of the Sprint thinking, “We planned smart – so why does it feel like we ran a marathon in sand?” you’ve met shadow work. It’s the effort your team expends that never makes it to the board, never gets sized, and never gets accounted for in capacity. It’s not bad work. It’s often essential work. But when it’s invisible, it erodes focus, predictability, and morale.
Let’s name it, frame it, and fix it.
What is shadow work?
We can bucket it into two flavors:
- Hidden effort inside “Done.”
Often teams size a story based only on coding effort alone and forget everything else that gets a backlog item from To-Do → Done: design, code review, test data creation, automation updates, multiple environment deployments, UAT coordination, security checks, refactoring, and the inevitable rework when something flakes in staging. When the team plans to the happy path and skips these realities, they “mysteriously” run out of time at the end of the sprint – usually when QA is staring at a mountain on the last day. - Off-board obligations that steal capacity.
This is the mentoring request from another group, the committee you “just” joined, the quarterly “dev days,” OKR side quests, production support pings, and those “could you just…” drive-bys. If it’s not on the Sprint Backlog, it’s not transparent, and it will tax your capacity.
Neither bucket is evil. Both must be visible.
The capacity myth: you don’t have eight hours a day
Even if you eliminated every Scrum event (please don’t!), nobody is doing eight hours of development a day. Humans need thinking time, context switches, hallway consults, and – yes – what we call futz time: the twenty-minute cluster at a pod where people share, ask, align, and reset. That social lubricant keeps teams human. It’s also capacity. Smart teams plan for it.
Practical starting points:
- Many Scrum product teams: plan ~6 hours/day of real delivery capacity.
- Mixed Teams that do new development while at the same time supporting a legacy product: explicitly split, e.g., 4 hours/day for new development, 2 hours/day for maintenance/support, tracked in a Kanban lane with its own policies.
- High-interrupt contexts: establish a predictable buffer (e.g., one hour/day/person) or a rotating “first responder” to shield the rest of the team.
The principle: if the time is predictably consumed, it must be explicitly accounted for.
Signs shadow work is biting you
- QA crunches at the end of every sprint; defects bounce back late.
- Your velocity is a roller coaster with no clear cause.
- Stories are “dev-done,” but the release stays stuck in UAT.
- Daily Scrum reveals brand-new obligations you didn’t plan.
- Team members feel “stuck in the middle” between managers and the Scrum Master.
If any of those ring true, the shadows are winning.
Make “Done” bigger (on purpose)
When teams size, they should size complexity to Done, not just “how long my bit will take.” Anchor to a shared reference item and ask:
- What will it really take to get this to production?
- Which environments will we touch?
- What are the likely failure or rework points?
- Does this area of the codebase have dragons (fragile, unfamiliar, or ugly)?
Invite QA, design, security, and DevOps voices into sizing. Use modified Fibonacci if you like, but resist the urge to add “5 for dev + 3 for QA.” You’re not summing sub-tasks; you’re agreeing on a single team complexity for the whole journey to Done.
Two friction-removers we love:
- Label exceptions up front. If a ticket truly doesn’t require code review or certain test suites, capture that in acceptance criteria so the flow is obvious and nobody gold-plates the journey.
- Front-load heavy QA items. If an item needs 300 test cases, commit early and start early. Don’t feed QA a mountain on Thursday.
Bring off-board work into daylight
If it consumes capacity, name it. Your playbook:
- Calendar sweep in Sprint Planning.
Have each person pop open their calendar for the next two weeks. Mark training, holidays, all-hands, recurring committees, interviews, support rotations – anything not directly tied to the Sprint Backlog. - Psychological safety + a prompt.
Normalize the question: “What are you working on that’s not on the board?” Ask it in Sprint Planning and occasionally in Daily Scrum. Celebrate the answers. You’re not scolding; you’re surfacing. - Agreements with adjacent leaders.
Ask engineering and functional managers to notify the Product Owner/Scrum Master before pulling team capacity for org work. No surprises. Respect goes both ways. - Plan it properly.
Choose one approach and stick to it for a few sprints:- Capacity offset: lower the sprint load (e.g., “We’re at 45 points this sprint because the team has two dev-days.”).
- Transparent spikes: create dedicated, time-boxed spikes for mentoring, training, or cross-team support only if you need the traceability. Avoid polluting velocity with non-product work unless it’s essential.
- Service lanes: for teams with continuous support, maintain a Kanban lane with clear WIP limits and explicit policies.
Quick wins you can run this week
1) Red Sticky Experiment
Give everyone a small stack of red sticky notes (or virtual tags). Any off-board task >20 minutes gets a red sticky and goes on the board. Review the pile in Retro. You’ll have instant evidence for patterns – and better planning next sprint.
2) Definition of Done tune-up
Expand your DoD to reflect reality: code review, automated tests updated, data seeded, security scan, environment deployment, rollback plan validated, UAT acceptance, release notes drafted. If it’s consistently needed, it belongs in DoD. Trim anything that’s theater.
3) “Sludge audit” (value stream glance)
Map the path of one recent story across your actual system: where did it sit, and why? Identify the stickiest delays (approval queues, test data waits, flaky environments) and remove or redesign one. Small change, big lift.
4) Capacity template
Adopt a simple per-person template in Sprint Planning:
- Working days this sprint
- Known absences (holidays, PTO)
- Org obligations (training, committees)
- Support rotation hrs
- Net delivery hours
Total it at the team level and load the sprint to ~80 – 85% of that number. The remaining buffer absorbs the unknowns without tanking the sprint.
5) Daily Scrum prompt
Rotate a lightweight prompt each day:
- “Anything you’re doing that’s not on our board?”
- “Any new org asks that impact your capacity today?”
- “Any blockers sitting in another team’s queue?”
Metrics that matter (and one you’ll invent)
- Flow metrics: monitor throughput, WIP, and cycle time trends. If WIP grows while throughput stalls, shadows are pulling capacity.
- Shadow Work Ratio (make it yours):
Track for 3 – 4 sprints to establish a baseline. If the ratio sits at 15 – 25%, build that into capacity or fix the upstream root causes.
Policies that protect your people
- Explicit intake: “If it’s not a Product Backlog item in this sprint, it doesn’t get worked – unless it’s a Sev-1.”
- Support WIP limits: cap the number of concurrent support issues in the Kanban lane.
- Service level expectations (SLEs): agree on response/turnaround times for support so it stops blowing up your core flow.
- Escalation path: if a manager attempts a mid-sprint pull, direct them to the Scrum Master/Product Owner. Individuals don’t negotiate capacity alone.
“But won’t we just oversize everything?”
Great question. Teams sometimes over-inflate story points to “cover” unknowns. Two antidotes:
- Improve the system, not the story. Reduce friction (fewer environments, stabilized pipelines, better test data) so all stories flow faster.
- Separate discovery from delivery. Use spikes for genuine research, time-box them, and make the learning visible. Don’t hide uncertainty in bloated points.
The people side: safety, transparency, and respect
Shadow work thrives where people feel they’ll be judged for “not doing enough.” Create a team culture where revealing constraints is an act of professionalism, not a confession. Leaders: model it. Say, “I’m pulling back our sprint load because training consumes two days for everyone.” That statement protects your team andeducates stakeholders.
Also – build relationships with adjacent managers. A five-minute weekly sync (“Anyone planning to borrow our people next sprint?”) can save your team from death by a thousand side quests.
When you bring shadow work into the light, two outcomes show up fast:
- Planning feels honest. The sprint’s not a wish list; it’s a commitment.
- People breathe again. Boundaries and transparency replace guilt and firefighting.
And here’s the best part: throughput often improves even when you plan less on paper, because the work you do plan actually flows. Less thrash, more finish. Less surprise, more trust.
Final thought
Shadow work isn’t a villain; invisibility is. Expand your Definition of Done, normalize capacity conversations, instrument the flow, and create light-giving agreements. When you do, your team will stop sprinting in sand and start delivering with calm confidence – without losing the human heartbeat that makes great teams great.