It's Not a "Project" — It's Brushing Your Teeth
You don't brush your teeth once a year for three days straight. You brush for two minutes every day. The daily habit is cheap, painless, and effective. The annual marathon is expensive, painful, and too late — the damage is already done.
Refactoring follows the same principle. Teams that treat refactoring as a separate "project" that needs management approval are already losing the entropy battle. By the time you've convinced a product manager to allocate a "refactoring sprint," the codebase has decayed to the point where refactoring is genuinely risky — which makes the product manager even less likely to approve the next one. It's a death spiral.
The alternative: bake refactoring into every ticket.
Here's how estimation should work:
| Ticket | Naive Estimate | Realistic Estimate (with hygiene) |
|---|---|---|
| Add email notifications | 2 days | 3 days (includes cleaning up NotificationService) |
| Fix checkout timeout | 1 day | 1.5 days (includes adding retry logic properly, not as a hack) |
| Add admin dashboard | 5 days | 6 days (includes extracting shared auth middleware) |
The extra time is not waste. It is the cost of sustainable velocity. Teams that skip hygiene ship faster in week 1 and slower in week 50. Teams that include hygiene ship at a consistent, predictable pace — which is what product managers actually want, even if they don't frame it that way.
How to talk about this with non-technical stakeholders:
Never say: "We need a refactoring sprint." This sounds like: "We want to spend two weeks producing zero business value because we made a mess."
Instead say: "This feature estimate includes time to ensure the notification system can support the three additional notification types on the roadmap. Without this work, each future notification type will take 3× longer to implement." This frames maintenance as investment in future velocity, which it is. You're not asking for permission to clean up — you're explaining why your estimate is what it is.
# A concrete example of how this shows up in a sprint
## Sprint 14 — Planned Work
### FEAT-2041: Add SMS Notifications
- Estimate: 5 story points
- Includes:
- Implement SMS provider integration (3 pts)
- Refactor NotificationService to support pluggable channels (2 pts)
### Note: The refactoring enables FEAT-2055 (Push Notifications)
### to be completed in 3 pts instead of the estimated 8 pts.
### Net saving: 5 pts on the next ticket alone.
The cost projection framing: When a PM pushes back on a higher estimate, show the numbers. "5 days now saves 3 days on each of the next 3 provider integrations. Total cost with refactoring: 5 + 2 + 2 + 2 = 11 days. Total cost without: 2 + 5 + 8 + 12 = 27 days." Concrete numbers change conversations.
Key Point: The most expensive refactoring is the one you postpone until it becomes an emergency. Continuous, small-scale refactoring embedded in feature work is cheaper in total cost, lower in risk, and doesn't require management approval. Senior engineers don't ask permission to write clean code — they include it in their estimates as a non-negotiable cost of professional software development.