Refactoring and the Product Backlog: Making Time for What Doesn't Show

Refactoring — improving the internal structure of code without changing its external behaviour — is one of the clearest examples of work that is essential and invisible. A team that refactors regularly ships features faster, produces fewer defects, and maintains a codebase that new developers can actually read. A team that skips refactoring under deadline pressure ships features faster in the short term and slower in every subsequent sprint, until eventually a significant portion of each sprint is consumed by working around problems that were knowable and preventable.

The pattern is familiar to every experienced Scrum team. It is also, persistently, a problem that experienced Scrum teams struggle to solve. The reason is structural: refactoring produces no visible output. There is no feature demo, no customer story, no release note. For a Product Owner managing a backlog full of stakeholder requests, allocating sprint capacity to work that produces nothing the business can point to requires both understanding and sustained commitment.

Why Refactoring Gets Squeezed Out

The pressure to skip refactoring is not irrational. In any given sprint, the team is choosing between delivering a user story that moves the product forward and improving code that produces no immediately observable benefit. Stakeholders who do not understand the internal state of the codebase — which is most stakeholders — will nearly always prefer the user story. The incentive to defer is real and constant.

Technical debt compounds this problem. Each deferred refactoring makes the next feature slightly harder to implement. The compounding is gradual and invisible until it is not — until a sprint that should take two weeks takes five, or a feature that should be straightforward requires touching a dozen fragile modules. By then, the cost of the original deferral is paid many times over, and the team is in a reactive position rather than a strategic one.

Strategy 1: Include Refactoring in the Definition of Done

The Definition of Done is the Scrum team's agreed standard for what it means for work to be complete. Including refactoring in the Definition of Done — specifically, that code touched in a user story leaves the module in a better state than it found it — inlines the work into normal delivery rather than treating it as a separate activity.

This approach works best when the standard is specific: not "code should be clean" (subjective and unenforced) but "if you add a function to a module, the module's test coverage must be at least as high when you leave as when you arrived." Concrete standards can be checked; vague aspirations cannot.

Strategy 2: Negotiate a Technical Debt Budget

A technical debt budget is an explicit agreement between the development team and the Product Owner about what percentage of each sprint's capacity is reserved for improvement work. Common allocations range from 10 to 20 per cent of sprint velocity. The exact percentage matters less than the agreement being explicit and durable — not renegotiated downward whenever a sprint has a full feature backlog.

Framing this negotiation in terms the Product Owner can act on is important. "We need time to clean up code" is a request that a feature-pressured Product Owner will defer. "We are currently accumulating approximately 15 per cent additional cost on every feature that touches the payment module because of the architectural decisions made in 2021 — here is a two-sprint investment that will reduce that to approximately 5 per cent" is a business case.

Strategy 3: Make Technical Debt Visible in the Backlog

Technical debt items belong in the product backlog, not in a separate engineering backlog that the Product Owner never sees. When refactoring work is invisible to the Product Owner, it cannot be prioritised — which means it will not be prioritised.

Writing technical debt items in business-impact language makes them comparable to feature requests. Not "refactor the authentication service" but "address authentication service fragility: the current implementation requires manual intervention an average of three times per month, each taking two hours of senior engineering time, and is estimated to be the most likely cause of our next major outage." That item can be placed on a backlog, estimated, and prioritised against features — because it is stated in terms that allow that comparison.

Strategy 4: Sprint Goals That Include Quality Work

Sprint Goals are a powerful but underused tool for protecting refactoring time. A Sprint Goal that names a quality outcome — "By the end of this sprint, the checkout module will have 80 per cent test coverage and the two known race conditions will be resolved" — commits the team publicly and gives the Product Owner a concrete outcome to communicate to stakeholders.

Sprint Goals that name only feature outcomes create pressure to drop quality work when time is short. Sprint Goals that name quality outcomes alongside feature outcomes create a shared commitment that is harder to quietly deprioritise.

The Product Owner's Responsibility

None of these strategies work without a Product Owner who understands why they matter. A Product Owner who consistently deprioritises refactoring in favour of features is not being irrational — they are responding to the incentives their stakeholders are creating. The team's job is to make the consequences of that deprioritisation visible and concrete, and to give the Product Owner the language to defend quality investments to stakeholders who may not immediately understand them.

The most effective Product Owners treat the codebase as a product asset — something that has a quality level, a maintenance cost, and an investment strategy — rather than as a black box that produces features. Building that understanding is a shared responsibility of the entire Scrum team, not just the developers.

XNM Consulting works with Scrum teams and product organisations to build the practices and governance structures that protect long-term delivery capacity. Learn more about our programme and project delivery services and how we help teams build sustainable delivery rhythms.