What Is Technical Debt?
Technical debt is the implied cost of future rework caused by choosing an easy (or quick) solution now instead of a better approach that would take longer.
Like financial debt, tech debt isn't inherently bad. Sometimes you need to ship fast and pay the interest later. The problem comes when you don't have a plan to pay it back—or when you don't even realize you're accumulating it.
The Credit Card Analogy
Financial Debt
- →Borrow money now, pay back later with interest
- →Minimum payments keep you afloat but don't reduce principal
- →Ignored debt compounds and eventually cripples spending power
- →Strategic debt (mortgage) vs reckless debt (maxed cards)
Technical Debt
- →Ship fast now, refactor later with extra effort
- →Quick fixes keep features shipping but don't improve codebase
- →Ignored debt slows velocity and eventually halts development
- →Strategic shortcuts (MVP) vs reckless code (no tests, no docs)
The key insight: Just like credit cards, technical debt has an interest rate. The longer you wait to pay it down, the more it costs in developer time, bug fixes, and lost velocity.
The Technical Debt Quadrant
Not all debt is created equal. Martin Fowler's quadrant helps categorize debt by intent and care:
Accidental & Prudent
"Now we know how we should have done it"
Learning debt—unavoidable as tech evolves
Deliberate & Prudent
"We must ship now and deal with consequences"
Strategic debt—calculated trade-off
Accidental & Reckless
"What's a design pattern?"
Ignorance debt—lack of skill or care
Deliberate & Reckless
"We don't have time for design"
Dangerous debt—shortcuts without thought
Deliberate & Prudent
Conscious decision to take shortcuts with a plan to fix later
Ex: Ship MVP without full test coverage to meet launch deadline
Deliberate & Reckless
Knowingly cutting corners without considering consequences
Ex: Skipping security review because "nobody will find it"
Accidental & Prudent
Learning from experience—better approach discovered later
Ex: Legacy code before the team understood current best practices
Accidental & Reckless
Poor practices from lack of knowledge or care
Ex: Junior developer shipping code without understanding patterns
How Debt Interest Accumulates
Skip writing tests for quick feature
Bug in untested code costs extra time
New feature breaks untested code
Team afraid to touch this module
Must rewrite from scratch—debt compounds
Notice the pattern: The original debt was only 2 points. By Sprint 5, the interest has grown to 11 points— more than 5x the original cost. This is why paying debt early is crucial.
How to Identify Technical Debt
Slowing Velocity
Sprint after sprint, the team completes fewer story points despite working harder.
Frequent Production Issues
Bug reports increase. Every new feature breaks something unrelated.
Fear of Touching Code
Developers avoid certain files or modules because "nobody understands that code."
Long PR Review Times
Pull requests sit for days because reviewers need hours to understand the context.
Onboarding Takes Forever
New team members take months to contribute because the codebase is impenetrable.
Copy-Paste Programming
Same logic appears in 10 different places because refactoring is "too risky."
Strategies for Paying Down Debt
The 20% Rule
Allocate 20% of every sprint to debt reduction alongside feature work.
Consistent progress, prevents debt accumulation
Less predictable delivery speed for stakeholders
Teams with moderate debt
Debt Sprint
Dedicate entire sprint(s) to refactoring and cleanup.
Deep focus, significant improvement
No new features for weeks, hard to justify
Crisis situations with severe debt
Boy Scout Rule
Always leave code better than you found it. Refactor as you work.
Zero explicit cost, continuous improvement
Slow, doesn't address worst areas
Preventing future debt
Opportunistic Refactoring
Fix debt when you're already touching related code for features.
No dedicated time needed, context is fresh
Unpredictable progress, cherry-picks easy wins
Teams with tight deadlines
Debt as Stories
Treat debt items as regular backlog stories with points and priority.
Visible in planning, competes with features
Requires stakeholder buy-in
Transparent agile teams
Debt Priority Matrix
Not all debt deserves immediate attention. Use this matrix to prioritize what to fix first:
DO FIRST
High pain, easy fix
Ex: Fix slow database query causing timeout errors
PLAN CAREFULLY
High pain, hard fix
Ex: Migrate legacy authentication system
OPPORTUNISTIC
Low pain, easy fix
Ex: Update deprecated library with drop-in replacement
DEFER
Low pain, hard fix
Ex: Refactor rarely-touched legacy module
How to Estimate Tech Debt in Planning Poker
Technical debt items are estimated the same way as features—using story points based on complexity, effort, and risk. The key difference: debt stories reduce future costs instead of adding new value.
Quick Fix
1-2 ptsSimple refactor, add missing test, update deprecated library
Example: Replace var with const/let across a file
Module Cleanup
3-5 ptsRefactor a component, extract duplicate code, improve naming
Example: Split 500-line component into smaller pieces
Architectural Fix
8-13 ptsRedesign data flow, replace anti-pattern, major dependency update
Example: Migrate from Redux to Context API in a feature
System Overhaul
21+ ptsBreak into smaller debt stories. Too large to estimate safely.
Example: Rewrite authentication system from scratch
Pro tip: When estimating debt, include the cost of testing and validation. Refactoring without tests is just moving furniture around in the dark.
Communicating Debt to Stakeholders
Different audiences need different messages. Here's how to frame technical debt for each stakeholder:
Product Owner
Show velocity decline graphMessage: Technical debt is deferred cost. Every sprint we delay, the "interest" grows.
Analogy: Like credit card debt—minimum payments keep you afloat, but you never get ahead.
C-Suite
Feature delivery speed trendMessage: Debt slows time-to-market. Paying it down is an investment in delivery speed.
Analogy: Factory maintenance—skip it now, face production shutdown later.
Customers
Incident resolution timeMessage: You don't tell them about debt directly. Show results: faster fixes, fewer bugs.
N/A—Keep technical details internal
Other Developers
Code complexity scoresMessage: Debt compounds. The longer we wait, the harder and riskier the fix becomes.
Analogy: Leaving dishes in the sink—crusty food is harder to clean later.
✓ Key Takeaways
- 1Technical debt isn't inherently bad—it's a tool. Strategic debt can accelerate delivery.
- 2Debt has interest. The longer you wait, the more expensive it becomes to fix.
- 3Use the debt quadrant to categorize debt by intent and care—not all debt is equal.
- 4Prioritize debt that causes high pain and is easy to fix—quick wins build momentum.
- 5Estimate debt like features using story points, and make it visible in your backlog.
- 6Tailor your message to stakeholders—show metrics they care about, not implementation details.
Estimate Tech Debt in Your Next Sprint
Use planning poker to estimate technical debt stories alongside features. Make debt visible and prioritize it with your team.
Start Planning Poker Session