Technical Debt

Technical debt is the implied cost of rework caused by choosing quick, limited, or incomplete solutions now instead of using better approaches that would take longer. For Agile teams, managing technical debt is a risk and quality strategy that ensures the product remains sustainable, maintainable, and able to evolve without incurring massive rework costs later. This topic appears in scenario-based questions on Agile risk management, quality trade-offs, sprint planning decisions, and product backlog prioritization.

Core Concepts

What Is Technical Debt

Technical debt occurs when the team deliberately or unintentionally takes shortcuts in design, coding, testing, or documentation to deliver features faster, knowing that these shortcuts will require future effort to correct or improve. It is not inherently bad-it is a strategic trade-off-but if left unmanaged, it accumulates and eventually slows down delivery, increases defects, and makes the product harder to change.

Common causes of technical debt include:

• Pressure to meet release deadlines with minimal viable features
• Intentional design simplifications to validate assumptions quickly
• Lack of automated testing or continuous integration
• Changing requirements that make earlier code obsolete
• Team turnover or knowledge gaps leading to poor design choices
• Deferred refactoring or code cleanup

When to Use This

• Use technical debt reasoning when the question asks whether to delay refactoring, accept a quick fix, or prioritize new features over code quality improvements.
• Recognize technical debt as the correct answer when the scenario describes increasing defect rates, slower velocity over time, or difficulty implementing new features due to legacy code.
• Choose technical debt management strategies when balancing short-term delivery pressure against long-term product health.

Types of Technical Debt

Understanding the type of technical debt helps teams decide how to manage it and when to pay it down.

When to Use This

• When the scenario asks whether the team should document a known shortcut or just move forward, choose to track deliberate technical debt explicitly.
• When velocity is declining and defects are increasing, recognize inadvertent or accumulated technical debt as the likely root cause.
• When the question describes outdated dependencies or libraries, identify it as bit rot and recommend scheduled maintenance work.

Managing Technical Debt in Agile

Agile teams manage technical debt by making it visible, prioritizing it against new features, and continuously paying it down to keep the product sustainable.

Key practices for managing technical debt:

• Make it visible: Add technical debt items to the product backlog just like user stories, with clear descriptions of the problem and the cost of delay.
• Allocate capacity: Reserve a percentage of each sprint (commonly 10-20%) for refactoring, code cleanup, and technical debt reduction.
• Involve the Product Owner: The Product Owner must understand the business impact of technical debt to make informed prioritization decisions.
• Include in Definition of Done: Require code quality standards, automated tests, and documentation as part of the DoD to prevent new technical debt from accumulating.
• Refactor continuously: Encourage developers to improve code incrementally during normal development work, not just in dedicated sprints.
• Track and communicate: Use metrics like code quality trends, defect rates, and velocity changes to show the impact of unmanaged technical debt to stakeholders.

When to Use This

• When the scenario asks how to handle accumulating technical debt, choose the approach that makes it visible in the backlog and allocates capacity to address it.
• When the Product Owner resists prioritizing technical debt work, explain the long-term cost of delay and declining velocity.
• When velocity is falling or defects are rising, recommend allocating sprint capacity specifically to technical debt reduction and refactoring.

Technical Debt vs. Defects

Technical debt and defects are related but distinct concepts, and the exam tests whether you understand the difference and when each requires different handling.

When to Use This

• When the scenario describes working software that is hard to change or test, classify it as technical debt, not a defect.
• When the scenario describes functionality that does not work as specified, classify it as a defect and fix it immediately.
• When deciding whether to defer a fix, choose deferral only if it is technical debt with understood trade-offs, not a defect blocking use.

Technical Debt Quadrant

The technical debt quadrant (developed by Martin Fowler) categorizes technical debt based on whether it was incurred deliberately or inadvertently, and whether it was reckless or prudent. This helps teams decide how to respond.

When to Use This

• When the scenario describes a conscious decision to skip quality steps to meet a deadline, classify it as deliberate and prudent-and plan to address it in upcoming sprints.
• When the scenario describes poor practices due to lack of knowledge, classify it as inadvertent and reckless-and address it through coaching and training.
• When deciding how to prevent future technical debt, strengthen the Definition of Done and provide continuous learning opportunities.

Communicating Technical Debt to Stakeholders

Many stakeholders do not understand technical debt because it is invisible to them until it causes delays or defects. The exam tests how you explain the cost of technical debt in business terms and engage the Product Owner in prioritization decisions.

Effective strategies for communicating technical debt:

• Use business language: Explain technical debt as "shortcuts that save time now but cost more later" rather than technical jargon.
• Show the trend: Use metrics like declining velocity, increasing defect rates, or longer cycle times to demonstrate the impact.
• Quantify the cost: Estimate how much longer features take to build or how many defects are caused by unmanaged technical debt.
• Propose trade-offs: Present options like "We can deliver three new features this sprint, or two new features plus reduce technical debt to speed up future sprints."
• Link to business risk: Explain how technical debt increases the risk of outages, security vulnerabilities, or inability to pivot when market conditions change.

When to Use This

• When the scenario asks how to get stakeholder buy-in for technical debt work, choose the approach that translates technical issues into business impact and risk.
• When the Product Owner questions why the team is slowing down, use velocity trends and defect data to show the cost of accumulated technical debt.
• When prioritizing between new features and technical debt, involve the Product Owner in the trade-off decision using clear business terms.

Commonly Tested Scenarios / Pitfalls

1. Scenario: The team is under pressure to deliver a feature by the end of the sprint, and developers propose skipping automated tests to finish on time. The Product Owner agrees because the feature is high priority. What should the Scrum Master do first?

Correct Approach: Facilitate a discussion with the team and Product Owner about the trade-offs, ensuring the decision to incur technical debt is explicit, tracked in the backlog, and scheduled for repayment in an upcoming sprint. The team should agree on when and how the tests will be added.

Check first: Whether the team and Product Owner understand that skipping tests creates deliberate technical debt that must be paid down soon, not ignored indefinitely.

Do NOT do first: Do not allow the team to skip the tests without documenting the decision or planning to address it later. This turns a deliberate, prudent decision into reckless technical debt accumulation.

Why other options are wrong: Telling the team they cannot skip tests at all ignores the valid business need to deliver quickly; allowing the skip without tracking it means the debt will likely never be repaid and will compound over time.

2. Scenario: Over the past three sprints, the team's velocity has declined from 30 story points per sprint to 20, even though the team size and sprint length have not changed. During the retrospective, developers mention that the codebase is becoming harder to change and that small changes now require modifying many parts of the system. What is the most likely root cause?

Correct Approach: Accumulated technical debt is slowing the team down. The team should allocate capacity in upcoming sprints to refactor the code, improve modularity, and reduce dependencies.

Check first: Whether the declining velocity coincides with increasing code complexity, longer testing cycles, or more defects-all signs of unmanaged technical debt.

Do NOT do first: Do not add more team members or extend sprint length first. This does not address the underlying issue that the codebase itself is the bottleneck.

Why other options are wrong: Adding team members may temporarily increase throughput but will not fix the structural problems in the code; changing team composition or sprint length does not reduce technical debt.

3. Scenario: The Product Owner insists that all sprint capacity be used for new features and refuses to prioritize technical debt items in the backlog. The team warns that this will eventually make the product unmaintainable. What should the Scrum Master do?

Correct Approach: Coach the Product Owner on the business impact of technical debt by showing trends in velocity, defect rates, and cycle time. Help the Product Owner understand the trade-off: paying down technical debt now will enable faster delivery of features later.

Check first: Whether the Product Owner understands that technical debt is not a technical preference but a business risk that affects long-term value delivery.

Do NOT do first: Do not let the team unilaterally decide to allocate capacity to technical debt without the Product Owner's buy-in. The Product Owner owns prioritization, so the Scrum Master must coach them to make informed decisions.

Why other options are wrong: Ignoring the Product Owner and doing the work anyway undermines trust and violates the Product Owner's authority; continuing without addressing technical debt will eventually cause severe delivery problems.

4. Scenario: During sprint planning, the team identifies a user story that cannot be implemented without first refactoring a core module. The refactoring is estimated at 13 story points, and the new feature is estimated at 8 story points. The team's velocity is 25 story points per sprint. What should the team do?

Correct Approach: Include both the refactoring work and the new feature in the sprint backlog if the total fits within the team's capacity. If not, work with the Product Owner to decide whether to defer the feature or reduce scope elsewhere to accommodate the necessary refactoring.

Check first: Whether the refactoring is truly a prerequisite for the new feature or whether it can be deferred. If it is a prerequisite, it must be done.

Do NOT do first: Do not implement the new feature on top of the poorly designed module without refactoring. This will add more technical debt and make future changes even harder.

Why other options are wrong: Skipping the refactoring to fit more features in the sprint creates additional technical debt and increases long-term risk; delaying the feature indefinitely may not be acceptable to the Product Owner.

5. Scenario: A team discovers during a sprint that a user story marked as done two sprints ago does not have any automated tests. The code works, but changes to related areas in the current sprint are causing unexpected failures. How should the team classify this issue?

Correct Approach: This is technical debt (missing tests), not a defect, because the original code worked as intended. The team should add a backlog item to create the missing tests and allocate capacity to address it in an upcoming sprint.

Check first: Whether the original code met the acceptance criteria at the time it was completed. If it did, the missing tests represent technical debt; if it did not, it was a defect that should have been caught earlier.

Do NOT do first: Do not treat this as a defect requiring immediate fixing unless it is blocking current work. Instead, track it as technical debt and prioritize it appropriately.

Why other options are wrong: Treating it as a defect overstates the urgency and may disrupt the sprint; ignoring it entirely allows the technical debt to grow and increases the risk of future failures.

Step-by-Step Procedures or Methods

Procedure: Adding Technical Debt to the Backlog and Tracking It

Task: Ensure technical debt is visible, prioritized, and addressed systematically.

1. Identify the technical debt: During development, retrospectives, or code reviews, identify code, design, or test gaps that will make future work harder or riskier.
2. Describe the debt clearly: Write a backlog item that explains what the technical debt is, why it was incurred, and what the cost of delay will be if it is not addressed.
3. Estimate the effort: Estimate the work required to pay down the technical debt in the same way you estimate user stories (e.g., story points or ideal hours).
4. Communicate the impact: Work with the team to quantify how the technical debt affects velocity, defect rates, or the ability to deliver new features.
5. Prioritize with the Product Owner: Present the technical debt item to the Product Owner along with the business impact, and work together to decide when it should be addressed relative to new features.
6. Allocate capacity: Reserve a percentage of each sprint (commonly 10-20%) for technical debt reduction, or schedule dedicated sprints if the debt is severe.
7. Track progress: Monitor trends in code quality, velocity, and defect rates to confirm that paying down technical debt is having the desired effect.

Procedure: Deciding Whether to Incur Technical Debt

Task: Make a deliberate, prudent decision about whether to take a shortcut that creates technical debt.

1. Identify the trade-off: Determine what quality, design, or testing step would need to be skipped to deliver faster.
2. Assess the business need: Confirm with the Product Owner whether the faster delivery provides enough business value to justify the shortcut.
3. Estimate the cost of delay: Estimate how much longer the skipped work will take if done later, and how much it will slow down future development if not addressed.
4. Document the decision: Create a backlog item describing the technical debt being incurred, why it was necessary, and when it should be repaid.
5. Schedule repayment: Work with the Product Owner to prioritize the technical debt item in an upcoming sprint-ideally within the next 2-3 sprints.
6. Communicate to the team: Ensure the whole team knows that the shortcut is temporary and that time is allocated to fix it properly.

Practice Questions

Q1: A Scrum team has been delivering features quickly for several sprints, but the Product Owner is concerned that velocity has started to decline. The developers explain that the codebase has become difficult to change and that small features now require extensive rework. What is the most likely cause?
(a) The team is not following the Definition of Done.
(b) The team has accumulated technical debt that is slowing down development.
(c) The Product Owner is not prioritizing the backlog effectively.
(d) The team needs additional training on Agile practices.

Ans: (b)
Declining velocity combined with increasing difficulty making changes is a classic sign of accumulated technical debt. When shortcuts are taken or refactoring is deferred, the codebase becomes harder to maintain and extend, slowing future development. Option (a) may be a contributing factor but does not explain the specific symptoms described. Option (c) is unrelated to code complexity. Option (d) does not address the root cause, which is the state of the codebase itself.

Q2: During sprint planning, the team realizes that implementing a new feature will require refactoring a poorly designed module. The refactoring will take significant effort but is necessary to proceed. What should the team do first?
(a) Implement the feature on top of the existing module and refactor later.
(b) Include both the refactoring and the new feature in the sprint backlog if capacity allows.
(c) Ask the Product Owner to defer the feature until a future sprint.
(d) Allocate a separate sprint solely for refactoring work.

Ans: (b)
If the refactoring is a prerequisite for the new feature, both must be included in the sprint backlog. This makes the true cost of the feature visible and ensures the work is done properly. Option (a) adds more technical debt and makes future changes harder. Option (c) may not be necessary if both pieces of work fit within the sprint capacity. Option (d) delays delivery unnecessarily if the refactoring can be done incrementally as part of the feature work.

Q3: The Product Owner refuses to prioritize technical debt items in the backlog, insisting that all capacity be used for new features. The team warns that this will eventually make the product unmaintainable. What should the Scrum Master do?
(a) Tell the team to allocate capacity to technical debt work without the Product Owner's approval.
(b) Coach the Product Owner on the business impact of technical debt using velocity trends and defect data.
(c) Escalate the issue to senior management to override the Product Owner's decision.
(d) Accept the Product Owner's decision and allow the team to focus only on features.

Ans: (b)
The Scrum Master's role is to coach the Product Owner to make informed decisions by explaining the business impact of technical debt in terms of velocity, defects, and long-term delivery risk. Option (a) undermines the Product Owner's authority and violates the Scrum framework. Option (c) bypasses coaching and collaboration, which should be tried first. Option (d) ignores the team's legitimate concerns and allows technical debt to compound unchecked.

Q4: A team discovers that a user story completed two sprints ago has no automated tests, and changes in the current sprint are causing unexpected failures. How should the team classify this issue?
(a) As a defect requiring immediate fixing.
(b) As technical debt to be tracked and prioritized in the backlog.
(c) As a violation of the Definition of Done that should be escalated.
(d) As a retrospective item for process improvement only.

Ans: (b)
If the original code worked but lacks tests, it is technical debt, not a defect. The missing tests should be added as a backlog item and prioritized appropriately. Option (a) overstates the urgency unless the failures are blocking current work. Option (c) is valid if the Definition of Done requires tests, but the immediate action is still to track and fix the gap. Option (d) does not address the specific issue of missing tests in the codebase.

Q5: A team is under pressure to meet a release deadline and proposes skipping code reviews to save time. The Product Owner agrees. What should the Scrum Master do first?
(a) Allow the team to skip code reviews to meet the deadline.
(b) Facilitate a discussion about the trade-offs and ensure the decision to incur technical debt is documented and scheduled for repayment.
(c) Refuse to allow the team to skip code reviews under any circumstances.
(d) Extend the sprint length to allow time for both the feature and code reviews.

Ans: (b)
The Scrum Master should ensure the decision to skip code reviews is deliberate, prudent, and tracked as technical debt with a plan to address it soon. Option (a) allows reckless debt accumulation without accountability. Option (c) ignores the valid business need to deliver quickly. Option (d) may not be feasible and does not address the core trade-off being made.

Q6: Which of the following best describes the difference between technical debt and a defect?
(a) Technical debt is code that does not work; a defect is code that works but is hard to maintain.
(b) Technical debt is code that works but is suboptimal; a defect is code that does not meet requirements or does not work as intended.
(c) Technical debt must be fixed immediately; defects can be deferred.
(d) Technical debt is always deliberate; defects are always inadvertent.

Ans: (b)
Technical debt refers to working code that has quality, design, or maintainability issues that will slow down future work. A defect is code that does not work correctly or does not meet acceptance criteria. Option (a) reverses the definitions. Option (c) is incorrect; defects are typically more urgent than technical debt. Option (d) is incorrect; technical debt can be either deliberate or inadvertent.

Quick Review

• Technical debt is the implied cost of rework caused by taking shortcuts in design, coding, testing, or documentation to deliver faster now.
• Deliberate technical debt is a conscious trade-off made to meet a deadline; inadvertent technical debt is discovered later as the team learns or requirements change.
• Make technical debt visible by adding it to the product backlog and estimating the effort to pay it down.
• Allocate 10-20% of sprint capacity to technical debt reduction and refactoring to prevent it from accumulating uncontrollably.
• Technical debt slows velocity over time, increases defect rates, and makes the product harder to change or extend.
• Communicate technical debt to stakeholders in business terms: "shortcuts that save time now but cost more later."
• Technical debt is not the same as a defect: technical debt is working code that is suboptimal; a defect is code that does not work as intended.
• Include refactoring and code quality improvements in the Definition of Done to prevent new technical debt from accumulating.
• When incurring technical debt deliberately, document the decision, track it as a backlog item, and schedule repayment in an upcoming sprint.
• Use velocity trends, defect rates, and cycle time metrics to show stakeholders the impact of unmanaged technical debt.