← Back to blog

Refactoring in sprints: how to justify and estimate

refactoring estimates quality

“Why are we spending time refactoring when it doesn’t deliver user value?” If you’ve heard that, you know refactoring needs to be sold, not requested.

Refactoring as business value

Refactoring delivers indirect but measurable value:

  • Velocity: clean code is faster to modify
  • Reliability: fewer bugs in well-structured code
  • Maintenance: faster onboarding, safer changes
  • Morale: developers are more productive and happier with clean code

Three approaches to refactoring

1. Continuous refactoring (Boy Scout Rule)

“Leave the code better than you found it.” Small improvements with every PR.

How to estimate: Already included in the feature estimate. If you’re touching a module, add 1-2 points to improve it.

When to use: Always. It’s the most sustainable approach.

2. Planned refactoring

Larger improvements that need dedicated focus.

How to estimate: Standard Planning Poker, like any other task.

Examples:

  • “Extract authentication service from the monolith” — 8 points
  • “Migrate module X from REST to GraphQL” — 13 points

When to use: For architectural changes or code with critical debt.

3. Hardening sprint

A sprint dedicated to technical quality.

How to estimate: List of improvements, each one estimated, filling up the sprint.

When to use: Rarely — only when technical debt has accumulated to the point of blocking deliveries.

How to justify it to stakeholders

With numbers

“This module causes 40% of our bugs. Refactoring it will reduce bugs by ~60%, saving ~8 hours/week on debugging.”

With analogies

“It’s like changing the engine while the car is running. It works, but it’s risky and slow. If we stop for 1 sprint to do it properly, the car runs fast again.”

With risk

“If we don’t refactor now, every new feature in this module will take 40% more time. In 3 sprints, the additional cost already exceeds the cost of refactoring.”

Estimating refactoring

Refactoring is estimated with Planning Poker just like any technical task. Your estimate should include:

  • Analyzing the current code
  • Writing the refactored code
  • Tests (verifying behavior hasn’t changed)
  • Code review
  • Deploy and smoke testing

The 80/20 rule for sprints

A healthy sprint:

  • 80%: new features and bugs
  • 20%: refactoring and technical improvements

If refactoring consumes more than 30%, there’s a systemic quality problem. If it consumes less than 10%, your technical debt is growing.

Refactoring vs. rewrite

Refactoring: improving structure without changing behavior. Low risk. Do it continuously.

Rewriting: building from scratch. High risk. Only do it when:

  • Legacy code is impossible to maintain
  • The technology is obsolete (e.g., jQuery to React)
  • Incremental refactoring is more expensive than a rewrite

Rewrites are notoriously dangerous. Estimate them at 2x whatever you think it’ll take.

Conclusion

Refactoring isn’t a luxury — it’s hygiene. Teams that refactor continuously deliver faster and with fewer bugs in the long run. Bake it into feature estimates, reserve 20% of each sprint, and back it up with data on business impact.