Scrum, day 32: technical debt as a product decision

Today's objective: explain a technical improvement in terms of its effect on future product choices, with enough evidence to discuss a proportionate response.

Read alongside: Mastering Professional Scrum, chapter 3, focusing on technical debt. Allow roughly five minutes for this companion, plus the assigned section.

Explain what the current design makes difficult

The fictional ShiftSwap product contains three separate pieces of code that decide how a request's status should be described. One serves the employee page, another the manager view, and another the message service. The rules began similarly but have gradually diverged.

A Developer proposes consolidating them. Elena hears that the team wants to spend a Sprint “cleaning up technical debt.” That phrase gives her little information about why the work matters now or what product opportunity it would support.

The discussion improves when the Developers explain the consequence: each status-related change requires finding and updating three interpretations, and a missed difference can produce contradictory information for users. The design consumes attention and makes future changes harder to trust.

Distinguish an improvement from unfinished quality work

First, the team checks whether the current product meets its Definition of Done. If a known behavior violates the agreed standard, describing it as optional cleanup would obscure unfinished or defective work.

A different situation arises when the product satisfies the current standard but its internal structure makes further changes costly. The duplicated status logic may work correctly today while increasing the effort and uncertainty of the next modification.

These situations can overlap, but they require an honest account. The team should not use the debt label to conceal a quality failure or to imply that every disliked design is an urgent product risk. The relevant question is what consequence the current condition creates and what evidence supports that claim.

Show a recent example of the cost

The Developers describe the last two status changes. One required updating all three locations and adding checks to ensure they agreed. The other initially changed only the manager view, causing a discrepancy discovered during verification.

They do not invent a precise financial cost from a vague memory. Instead, they show the work revisited, the questions that took time to resolve, and the uncertainty that remains. If useful, they can collect better information during the next relevant change.

This evidence makes the discussion concrete. Elena can connect the proposed improvement to upcoming requests rather than compare an abstract appeal for engineering quality against a visible feature request.

Consider where the product is likely to change

If the next several product ideas depend on request state, the duplicated logic may constrain an important area of development. If the product is about to retire that workflow, a substantial redesign may have little opportunity to repay its cost.

The team cannot know the future perfectly. It can still compare plausible directions. Elena explains which user problems appear likely to receive attention. The Developers explain how the current design affects those options and which assumptions could change the recommendation.

This conversation connects technical knowledge with product judgment. Neither side can make a well-informed decision alone if the other withholds the information it holds.

Propose a bounded response

One option is to rewrite the entire request model. Another is to consolidate the status interpretation while implementing the next relevant change, preserving existing behavior and adding checks around the transition. A third is to leave the design in place temporarily and strengthen checks for consistency.

The Developers compare scope, uncertainty, and likely benefit. The narrower consolidation may address the recurring cost without creating a large migration. Stronger checks might reduce immediate risk while leaving duplication to revisit later.

There is no universal rule that all debt must be removed before features continue. The decision depends on the consequences, the product direction, the effort of the response, and the quality obligations that already apply.

Preserve an honest delivery forecast

If the team chooses consolidation, it belongs in the visible plan. Hiding it inside unrelated estimates can make the product discussion less transparent. Equally, demanding that every internal improvement be justified as a separately marketable feature would make necessary engineering work difficult to discuss.

The Developers can explain the work at a useful level: consolidate request-state interpretation so the next changes do not require maintaining three competing rules. The detailed implementation remains their responsibility.

Elena can then consider the work alongside other needs with a clearer understanding of what it enables. The team should include verification and any migration work in its forecast rather than describing only the attractive central change.

Inspect whether the improvement changes future work

After the consolidation, a tidy diagram is not the whole result. The team can examine the next status-related change. Did it require fewer places to update? Were the important rules easier to understand? Did the checks reveal unintended behavior? Did the consolidation create a new dependency or a confusing abstraction?

Some benefits become visible only over time. That does not make them imaginary, but it limits what the team can claim immediately. It can distinguish evidence already observed from benefits it expects to see later.

If the improvement fails to reduce the difficulty, the team should investigate its assumptions. Perhaps the main cost came from unclear product rules rather than duplicated code. A technical intervention cannot by itself resolve a decision that stakeholders have not made.

Write a product-facing explanation

Choose a technical condition your team wants to improve. Describe one recent consequence, the upcoming work it may affect, and a bounded response. Include what will remain unchanged or unresolved after that response.

Compare the proposal with doing nothing for now and with a smaller intervention. State what evidence would make you choose differently. Avoid relying on “best practice” as the entire explanation; identify the practical cost or constraint in this product.

Reflection: if a stakeholder cannot understand why the improvement matters, what consequence have you not yet explained? If you cannot identify one, what further investigation would help distinguish a useful investment from a personal preference?

Next, day 33 asks whether completed product work produces the benefit the team intended.