Refactoring can be hard for product owners to prioritize because the benefit is often invisible to users.
A new feature is easy to explain. A fixed defect is easy to explain. A performance improvement is usually easy to explain.
Refactoring is different. Done well, it changes the structure of the code without changing what the product does. The product may look exactly the same afterward.
That does not mean refactoring lacks business value.
The product owner’s question should not be, “Is this technical work or business work?” The better question is:
Will doing this work improve our ability to deliver valuable product changes?
Sometimes the answer is yes. Sometimes it is no. The team’s job is to make the tradeoff visible enough that the product owner can make a responsible decision.
What Refactoring Is
Refactoring means changing the structure of code without changing its behavior.
A team does not refactor in order to fix a bug. Fixing a bug changes what the product does.
A team might refactor, however, because the current code is making bugs more likely, slowing down changes, increasing testing effort, or making future work unnecessarily risky.
That distinction matters.
Refactoring is not automatically worth doing just because the code could be cleaner. But it should not be dismissed just because users will not see a new feature when the work is done.
Product owners do not need to understand every technical detail of a refactoring. They do need enough information to compare the refactoring with other product backlog items.
The Product Owner’s Refactoring Question
When a team proposes refactoring, the product owner should ask:
What product cost are we currently paying because we have not done this?
That cost may show up as:
- Defects in the same area of the product
- Slower delivery of related features
- Extra testing effort
- Higher risk when making changes
- Repeated dependence on one person who understands the code
- Delays caused by fragile integrations or unclear design
The more clearly the team can connect the technical problem to product impact, the easier the decision becomes.
A vague request to “clean up the code” is hard to prioritize. A specific statement like, “This part of the system has caused 120 hours of defect work over the last six sprints, and we believe a 40-hour refactoring will cut that roughly in half,” gives the product owner something useful to evaluate.
A Four-Step Way to Evaluate Refactoring
A team can make the economics of refactoring visible with four estimates:
- Estimate the cost of the current situation.
- Estimate the effort to refactor.
- Estimate the savings after refactoring.
- Estimate the payback period.
These estimates do not need to be perfect. They need to be good enough to support a decision.
Step 1: Estimate the Cost of the Current Situation
Start by looking at what the team is already paying because the code remains as it is.
Use actual data when possible. Look at defects, support issues, failed tests, rework, production incidents, or time spent understanding the code before making changes.
A useful window is often the last three months or the last six sprints. That is usually enough data to spot a pattern without turning the analysis into a research project.
Suppose a team looks at the last six two-week sprints and finds this:
- 8 high-severity defects in one area of the system
- 4 medium-severity defects in the same area
- 3 low-severity defects still open
The team does not track exact hours spent fixing each defect, so they estimate conservatively.
They estimate each high-severity defect took about 12 hours to investigate, fix, test, and discuss. They estimate each medium-severity defect took about 6 hours.
That gives them:
8 × 12 hours = 96 hours 4 × 6 hours = 24 hours
Total: 120 hours over six sprints
That means the team has been spending about 20 hours per sprint dealing with defects in this area.
The number does not need to be exact. It needs to be honest. If the team exaggerates the cost, they may win this argument and lose credibility for the next one.
What About Unfixed Bugs?
Unfixed bugs require judgment.
If the product owner would have liked those bugs fixed but could not justify the time, include them in the estimate. They are part of the cost of the current situation.
If the bugs are genuinely minor and unlikely to be fixed, leave them out.
The goal is not to make the case for refactoring look as strong as possible. The goal is to make the tradeoff clear.
Step 2: Estimate the Effort to Refactor
Next, estimate the refactoring itself.
Treat it like any other product backlog item. The team should discuss the work, identify the likely tasks, and estimate the effort.
The estimate should include more than just coding. Depending on the work, it may include:
- Updating tests
- Reviewing risky code paths
- Migrating data
- Validating affected workflows
- Coordinating with other teams
- Monitoring after release
Suppose the team estimates the refactoring will take 40 hours.
That estimate should be in the same unit used in step one. If the cost of the current situation was estimated in hours, estimate the refactoring in hours. If the team uses story points for both defect work and refactoring, story points can work as well.
The unit matters less than consistency.
Step 3: Estimate the Savings
Now estimate what will improve after the refactoring.
In the example above, the team has been spending about 20 hours per sprint fixing defects in this part of the system.
It would be unrealistic to claim refactoring will eliminate all of that work. A better estimate is conservative.
The team might say:
“We do not expect this to eliminate all defects in this area. But we believe it will reduce the time spent on these problems by about half.”
That means the team expects to save about 10 hours per sprint.
This is where many teams make their case too hard to believe. They imply refactoring will make the code clean, eliminate future problems, and make all related work faster.
Maybe it will help that much. But product owners should make decisions based on the benefits the team can reasonably defend.
Step 4: Estimate the Payback Period
The payback period shows how long it will take for the refactoring to repay the time invested.
Use this formula:
Effort to refactor ÷ savings per sprint = payback period
In this example:
40 hours to refactor ÷ 10 hours saved per sprint = 4 sprints
That means the team expects the refactoring to pay for itself after four sprints. After that, the team should have more capacity available for product work than it had before.
This is the kind of information a product owner can use.
The decision may still be no. There may be a critical deadline, a short product life, or a more valuable opportunity elsewhere in the backlog.
But now the conversation is about product economics, not whether the team “deserves” time to improve the code.
How Short Should the Payback Period Be?
There is no universal rule.
A four-sprint payback might be excellent for one product and too slow for another. The right answer depends on context.
A shorter payback period is more attractive when:
- The affected product area changes often
- The team expects to keep working in that area
- The product has a long remaining life
- The current code is causing repeated defects or delays
- Upcoming features depend on the same code
A longer payback period may still be worth accepting when the risk is high. For example, a refactoring that reduces release risk in a revenue-critical part of the product may be worth doing even if the savings are harder to measure.
A long payback period is harder to justify when the product is near retirement, the affected area rarely changes, or the refactoring is mostly about making the code look better to the team.
Product Owners Decide Priority, Not Design
The product owner should not decide how the team refactors.
That is a development decision.
The product owner should decide where the work fits relative to other product backlog items. That requires understanding the cost, benefit, timing, and risk.
A good refactoring proposal gives the product owner enough information to make that decision without dragging them into technical design.
The team might say:
“We’ve spent about 120 hours over the last six sprints fixing defects in this area. We estimate this refactoring will take about 40 hours. We believe it will save about 10 hours per sprint by reducing the defects and testing effort in this part of the system. That gives us a payback period of about four sprints. It also reduces risk on the reporting changes we expect next quarter.”
That is a product conversation.
When Refactoring Belongs in the Product Backlog
Some refactoring should be part of normal development. If the team is already changing a section of code to add a feature, small refactorings may simply be part of doing the work well.
Other refactorings are large enough that they need to be visible in the product backlog. They compete with features, fixes, and other product work. Those refactorings should be discussed during product backlog refinement so the team and product owner can decide whether the work is ready, valuable, and appropriately timed.
A refactoring item belongs in the backlog when it consumes meaningful capacity and affects product tradeoffs.
It should be written in a way that makes the outcome clear. For example:
“Refactor the pricing rules module so changes to discount logic can be made with less regression risk.”
That is more useful than:
“Clean up pricing code.”
The first version gives the product owner something to evaluate. The second asks for trust without explaining the tradeoff.
Warning Signs the Case Is Weak
A team should be cautious about asking for refactoring when the case depends on vague claims.
Warning signs include:
- “The code is bad” is the main argument.
- The team cannot explain what product work is being slowed down.
- The proposed refactoring is really a rewrite.
- The benefit depends on work the product owner does not expect to prioritize.
- The team cannot identify a reasonable stopping point.
- The refactoring is too large to evaluate as one decision.
None of these automatically mean the work is wrong. They mean the case is not yet strong enough.
The team may need to split the work, gather more data, connect the refactoring to upcoming backlog items, or handle smaller improvements as part of related feature work.
Make the Tradeoff Visible
Refactoring is easy to under-prioritize when the benefit is invisible. It is also easy to over-prioritize when the team talks only about technical discomfort.
The right conversation sits between those extremes.
A product owner should not approve refactoring just because the team wants cleaner code. And a team should not have to pretend technical work has no product value unless it creates a visible feature.
Use the economics.
Estimate what the current code is costing. Estimate what the refactoring will take. Estimate what will improve. Then compare the payback period against the other work competing for the team’s time.
That gives the product owner what they need: a clear tradeoff, stated in product terms.