Managing Technical Risk and Debt: A Comprehensive Guide for PSM II
Introduction
Managing Technical Risk and Debt is a critical competency area within the Professional Scrum Master II (PSM II) certification. It falls under the broader domain of Developing and Delivering Products Professionally, which emphasizes the Scrum Master's role in helping teams build high-quality, sustainable products. Understanding how technical risk and debt affect a team's ability to deliver value is essential for any advanced Scrum Master.
Why Is Managing Technical Risk and Debt Important?
Technical debt and technical risk are among the most insidious threats to product development. Here is why managing them matters:
1. Sustainable Pace: Unmanaged technical debt slows teams down over time. What once took hours begins to take days. Teams that ignore technical debt eventually grind to a halt, unable to deliver new features without breaking existing ones.
2. Transparency: A core pillar of Scrum is transparency. Hidden technical debt obscures the true state of the product, making it difficult for stakeholders to make informed decisions. If the Product Owner doesn't understand the cost of technical debt, they cannot make sound prioritization decisions.
3. Value Delivery: Technical risk and debt directly impact the team's ability to deliver value. Every Sprint spent patching fragile code or working around architectural limitations is a Sprint not spent delivering new customer value.
4. Quality and the Definition of Done: A strong Definition of Done is the primary defense against accumulating technical debt. When teams cut corners — skipping tests, ignoring code reviews, or deferring refactoring — they are taking on debt that will have to be repaid later, often with interest.
5. Predictability: Excessive technical debt makes forecasting unreliable. Teams cannot predict how long work will take when they are constantly fighting fires caused by accumulated debt.
6. Stakeholder Trust: When products become unreliable or slow to evolve, stakeholder trust erodes. Managing technical risk proactively preserves the relationship between the Scrum Team and its stakeholders.
What Is Technical Debt?
Technical debt is a metaphor coined by Ward Cunningham that describes the implied cost of additional rework caused by choosing an easy or limited solution now instead of a better approach that would take longer. It encompasses:
- Intentional (Deliberate) Debt: The team knowingly takes a shortcut. For example, shipping a quick fix to meet a deadline with the understanding that it will be refactored. This is sometimes a valid strategic choice, but only when made transparently and with a plan to repay it.
- Unintentional (Accidental) Debt: Debt that accumulates through lack of knowledge, poor practices, or evolving understanding of the problem domain. For example, a design choice that seemed sound at the time but becomes problematic as the system grows.
- Bit Rot: Over time, even well-written code can degrade as the technology ecosystem changes around it — libraries become deprecated, security vulnerabilities emerge, and dependencies evolve.
What Is Technical Risk?
Technical risk refers to uncertainties in the technical domain that could negatively impact the product. This includes:
- Architectural decisions that may not scale
- Integration challenges with third-party systems
- Performance unknowns under load
- Security vulnerabilities
- Unproven technologies or platforms
- Dependencies on external teams or vendors
Technical risk differs from technical debt in that risk is about uncertainty and potential future problems, while debt is about known compromises that have already been made. However, unmanaged risk often becomes debt.
How Does Managing Technical Risk and Debt Work in Scrum?
Scrum provides several mechanisms to address technical risk and debt. Understanding how these mechanisms work is essential for the PSM II exam:
1. The Definition of Done (DoD)
The Definition of Done is the primary tool for preventing new technical debt. A robust DoD ensures that every Increment meets a minimum quality standard. Key points:
- The DoD should include criteria such as code reviews, automated testing, documentation, performance standards, and security checks.
- If the DoD is weak or not enforced, technical debt accumulates with every Sprint.
- The Scrum Team owns the DoD and should strengthen it over time as their capabilities mature.
- Undone work (work that does not meet the DoD) is a form of technical debt and a risk to transparency.
- A Scrum Master should coach the team and the organization on the importance of a strong DoD and help remove organizational impediments that prevent the DoD from being comprehensive.
2. Sprint Backlog and Product Backlog
- Technical debt items should be made visible in the Product Backlog. This makes debt transparent to the Product Owner and stakeholders.
- The Product Owner is responsible for ordering the Product Backlog, but the Developers are responsible for advising the Product Owner on the technical implications of deferring debt repayment.
- Technical debt work does not need to be separated into a special backlog. It should be part of the single Product Backlog to maintain transparency.
- During Sprint Planning, the Developers should consider technical debt as part of their capacity and include debt-reduction work in the Sprint Backlog when appropriate.
3. Sprint Retrospective
The Sprint Retrospective is a key event for discussing technical practices, identifying sources of debt, and creating actionable improvement plans. Developers can:
- Identify areas of the codebase that are slowing them down
- Propose improvements to the Definition of Done
- Agree on technical practices (e.g., pair programming, test-driven development, continuous integration) that reduce future debt
- Create actionable improvement items that may be included in the next Sprint Backlog
4. Increment and Continuous Integration
- Every Increment should be potentially releasable and meet the Definition of Done. This forces the team to address quality continuously rather than deferring it.
- Continuous integration and continuous delivery (CI/CD) practices help catch issues early and prevent debt from accumulating.
- Automated testing suites serve as a safety net that allows teams to refactor confidently.
5. The Role of the Scrum Master
The Scrum Master plays a vital role in managing technical risk and debt, not by making technical decisions, but by:
- Coaching the team on the importance of quality and sustainable development practices
- Facilitating conversations between Developers and the Product Owner about the cost of technical debt
- Making debt visible — helping the team create transparency around the state of technical debt
- Protecting the Definition of Done — ensuring the team does not weaken the DoD under pressure
- Educating stakeholders — helping stakeholders understand that cutting quality does not actually speed things up; it slows them down over time
- Removing impediments — addressing organizational barriers that force teams to accumulate debt (e.g., unrealistic deadlines, insufficient tooling, lack of test environments)
- Encouraging engineering excellence — promoting practices like TDD, refactoring, pair programming, and code reviews without mandating specific technical solutions
6. Managing Technical Risk Through Empiricism
Scrum's empirical approach is inherently suited to managing technical risk:
- Inspection: Regularly inspect the product Increment and the technical health of the codebase. Use Sprint Reviews and Retrospectives as inspection points.
- Adaptation: When risks are identified, adapt the approach. This might mean creating a spike (a time-boxed exploration) to reduce uncertainty, reordering the Product Backlog to address high-risk items earlier, or investing in architectural improvements.
- Transparency: Make risks visible. Use information radiators, burndown charts, and explicit risk registers. Ensure the Product Owner understands technical risks and their potential impact on the product.
Common Anti-Patterns to Recognize
For the PSM II exam, it is important to recognize anti-patterns related to technical risk and debt:
- Ignoring technical debt to maximize feature delivery: This creates the illusion of velocity but leads to decreasing throughput over time.
- Hardening Sprints or Stabilization Sprints: These are signs that the DoD is insufficient. If you need a special Sprint to stabilize the product, quality is not being built in every Sprint.
- Separate teams for testing or bug-fixing: This fragments accountability and delays feedback. Cross-functional teams should own quality end to end.
- Lowering the Definition of Done under pressure: This is a short-term gain with long-term consequences. A Scrum Master should coach the team and organization to resist this temptation.
- Hidden or invisible technical debt: When debt is not tracked or communicated, the Product Owner cannot make informed decisions.
- Over-engineering: While debt is problematic, so is spending excessive time on hypothetical future needs. Scrum values delivering value now while maintaining quality.
- Not involving the Product Owner in technical debt discussions: The Product Owner needs to understand the implications of debt to make sound ordering decisions. The Developers have a responsibility to provide this transparency.
The Relationship Between Technical Debt and Velocity
An important concept for PSM II:
- As technical debt increases, velocity tends to decrease over time, even though the team's effort remains constant. This is because more and more effort goes toward working around problems rather than delivering new value.
- A sudden increase in velocity might indicate that the team is cutting corners and accumulating debt, not that they are becoming more productive.
- A temporary decrease in velocity when a team starts addressing technical debt is normal and expected. The long-term payoff is increased and more stable velocity.
Strategies for Addressing Existing Technical Debt
- Boy Scout Rule: Leave the code better than you found it. Every time the team touches a part of the codebase, make small improvements.
- Dedicated Backlog Items: For significant debt, create explicit Product Backlog Items that describe the debt and the value of addressing it.
- Refactoring as Part of Done: Include refactoring in the Definition of Done so it happens continuously.
- Incremental Improvement: Address debt incrementally rather than attempting a large-scale rewrite, which carries its own risks.
- Strengthen the DoD: Gradually raise the bar to prevent new debt from being created.
Exam Tips: Answering Questions on Managing Technical Risk and Debt
The PSM II exam tests your ability to apply Scrum principles to complex, real-world situations. Here is how to approach questions about technical risk and debt:
1. Always Favor Transparency
If an answer choice involves making technical debt visible to stakeholders and the Product Owner, it is likely a strong candidate. Scrum is built on transparency, and hiding debt violates this principle.
2. The Definition of Done Is Central
Many correct answers will involve strengthening, enforcing, or evolving the Definition of Done. Remember: the DoD is the primary mechanism for preventing new debt. If a question asks how to prevent technical debt, look for answers related to the DoD.
3. The Product Owner Must Be Informed, Not Bypassed
The Developers should make the Product Owner aware of technical debt and its consequences. However, the Product Owner ultimately orders the Product Backlog. Answers that suggest Developers should secretly fix debt without informing the Product Owner, or that the Product Owner has no role in technical debt decisions, are typically incorrect.
4. Avoid Answers That Suggest Separate Phases or Teams
Answers that suggest hardening Sprints, stabilization phases, or separate testing teams are usually incorrect. These indicate a lack of cross-functionality or an insufficient Definition of Done.
5. Self-Management of the Developers
The Developers are self-managing and decide how to do the work. This includes deciding on technical practices, refactoring approaches, and how to manage the technical quality of the product. Answers where the Scrum Master or Product Owner dictates technical solutions are generally incorrect.
6. The Scrum Master Coaches, Does Not Dictate
The Scrum Master's role is to coach the team on quality, facilitate conversations about debt, and help stakeholders understand its impact. The Scrum Master should not be making technical decisions or mandating specific engineering practices. Look for answers where the Scrum Master enables and educates rather than directs.
7. Think Long-Term and Sustainable
Scrum emphasizes sustainable development. Answers that sacrifice long-term health for short-term gains are usually traps. Choose answers that balance delivering value now with maintaining the ability to deliver value in the future.
8. Empiricism Over Prediction
When dealing with technical risk, favor empirical approaches: inspect and adapt, use spikes to reduce uncertainty, address the highest-risk items early in the project, and build working software to validate assumptions rather than relying on extensive upfront analysis.
9. Watch for the Word 'Undone'
Undone work is work that does not meet the Definition of Done but has been included in an Increment or considered complete. This is a form of technical debt and a transparency issue. Questions about undone work typically test your understanding that all work should meet the DoD before being considered part of a Done Increment.
10. Quality Is Non-Negotiable
In Scrum, quality is not variable. Scope can be negotiated, but quality should not be. If a question asks what should be adjusted when time is short, the answer is scope (reducing the number of Product Backlog Items), not quality (weakening the DoD).
11. Technical Debt Belongs in the Product Backlog
There should be a single Product Backlog. Technical debt items belong there alongside feature work. Answers that suggest separate backlogs for technical work or that technical debt should be hidden from stakeholders are incorrect.
12. Context Matters
PSM II questions often present nuanced scenarios. Consider the context carefully. Sometimes taking on deliberate, transparent technical debt is a valid strategic decision — for instance, to meet a critical market window. The key is that it is done knowingly, transparently, and with a plan to address it.
Summary
Managing technical risk and debt is not just a technical concern — it is a Scrum concern. It directly impacts transparency, the ability to deliver Done Increments, stakeholder trust, and the team's long-term capacity to deliver value. As a PSM II candidate, you must understand:
- What technical debt and risk are, and how they differ
- How Scrum's framework elements (DoD, Product Backlog, Retrospective, Increment) address debt and risk
- The Scrum Master's role in coaching, facilitating, and creating transparency
- The anti-patterns that signal poor management of technical debt
- How empiricism helps manage technical risk
- That quality is not negotiable, and that sustainable pace requires continuous attention to technical excellence
By internalizing these principles, you will be well-prepared to answer PSM II questions on this topic with confidence and accuracy.
