
Stream a simulated run, inspect the notifications it would send on Slack and email, and see exactly where it sits in the 7-stage PM OS flow. No password required.
The short version
The Tech Debt Analyzer agent quantifies which debt items are actually slowing velocity. It runs every Monday at 10 AM, analyzes the last 4 sprints of Jira data, correlates each debt area with velocity impact (auth refactor affects 5% of stories vs. legacy data layer affects 40%), and maps upcoming features to the debt they'll touch. The output is a prioritized list scored by (impact × urgency) / effort, with a payback calculation: "Fixing the data layer costs 40 dev-weeks but saves 20 dev-weeks per quarter going forward." Stop guessing which debt matters. Start fixing the data layer first.
Your tech debt backlog is sprawling. You have 50 items. Some are critical, some are "nice to eventually fix." You don't know which ones are actually slowing you down. The Impact Loop shows how velocity and outcomes connect; this agent quantifies the debt side of that equation.
So you either: (a) ignore them and watch velocity decline, or (b) allocate too much sprint time to debt and miss features your customers want.
The Tech Debt Analyzer agent quantifies the impact. Every Monday, it analyzes: which debt items are actually slowing engineering velocity? For each one, what's the cost of carrying it vs. the cost of fixing it? Then it produces a prioritized list.
"The auth refactor is painful but affects 5% of stories. The legacy data layer affects 40% of feature work. Fix the data layer first."
How It Works
The agent pulls data from three sources and applies scoring:
Backlog analysis: Every tech debt ticket in Jira/Linear, tagged as tech debt. For each one: description, status, estimated effort, age, and related features.
Velocity correlation: The agent analyzes: which stories touched which debt areas? How much slower did they move? If stories that touch the auth system take 40% longer, that's signal.
Feature impact: Which upcoming features will hit the most tech debt? If your top 3 prioritized opportunities all require fixing the data layer, that's urgent debt.
The output: a prioritized list scored by impact and urgency.
Data Sources and Setup
Prerequisites: You'll need:
- Jira or Linear: Tech debt backlog, tagged clearly, linked to features
- Sprint history: 4+ past sprints with story points and actual completion time
- Feature backlog: Upcoming features mapped to affected systems
- Engineering input: Qualitative assessment of which systems are painful
- Deployment/incident data: Are tech debt areas causing incidents or slow releases?
Schedule: Weekly Monday at 10 AM. Analyzes past sprints and upcoming quarter. Pair this with the Auto Bugfix Agent to handle the high-frequency bugs that surface once you clear the structural debt.
The Claude Prompt
You are analyzing tech debt impact on velocity and prioritizing what to fix first.
Here's our tech debt backlog:
[DEBT ITEMS: description, estimated effort, age, status, related systems/features]
Here's our sprint history (past 4 sprints):
[SPRINT DATA: stories completed, stories touching each debt area, actual time spent]
Here's our upcoming priorities:
[UPCOMING: top 10 features planned for next quarter, systems they touch]
Here's our baseline engineering data:
[BASELINE: team size, average velocity, story point estimates, deployment frequency, incident rate]
Please analyze and report:
1. **Velocity Impact Analysis**
For each major debt area (auth, data layer, API, etc.):
- How many stories touch this area per sprint (avg)?
- Stories in this area: average velocity impact vs. baseline
- If a story touches this area, how much slower does it move?
- Is the impact quantifiable? (e.g., +25% time) or qualitative? (devs complain)
2. **Upcoming Feature Impact**
- Which debt areas will upcoming features require?
- If we don't fix the debt, how much slower will feature work be?
- Rough estimate: fixing the debt saves X developer-weeks over the next quarter?
3. **Debt Prioritization**
Score each debt item by:
- Impact on velocity (how many stories affected?)
- Upcoming feature pressure (will we need to fix this soon?)
- Effort to fix (how much investment?)
- Risk of not fixing (does it cause bugs, incidents, or outages?)
- Priority score: (impact × urgency) / effort
- Recommend: top 3 debt items to fix next
4. **Debt Lifecycle**
- Which debt is getting worse? (old and still untouched)
- Which debt was created recently but is already causing pain?
- Are we creating new debt faster than we're fixing old debt?
5. **Payback Calculation**
For each of the top 3 priorities:
- Effort to fix
- Developer-weeks saved over next quarter (if fixed)
- Effort to fix vs. savings: is it worth it?
6. **Risk Factors**
- Is any debt causing production incidents?
- Is any debt making releases slow or risky?
- Is any debt blocking security or compliance?
Format as a prioritized action plan. Be specific: engineering should be able to pick the top item and start immediately.
What You Get
Instead of guessing which debt matters:
- Quantified impact: You know exactly which debt slows velocity most
- Prioritized roadmap: Fix the high-impact items first
- Business case: You can show: "Fixing the data layer costs 40 dev-weeks but saves 20 dev-weeks/quarter in velocity gains"
- Visibility: Engineering knows why debt is prioritized, not just "PM says fix this"
Real outcomes:
- You allocate the right amount of sprint time to debt (not too much, not too little)
- Velocity improves because you're removing bottlenecks
- Engineering is happy because you're fixing the painful stuff first, not random items
For the full agent fleet and scheduling details, see Your AI Agent Fleet.
Also on Medium
Full archive →Is Mob Programming the Right Approach for Your Team?
When mob and pair programming work, when they don't, and how to read the trade-offs.
AI Agents and the Future of Work: A Pixar-Inspired Journey
What product managers can learn about AI agents from how Pixar runs a film team.
Frequently asked
What does the Tech Debt Analyzer agent do?+
Every Monday at 10 AM, it analyzes the last four sprints of Jira data to measure which tech debt areas are actually slowing velocity, maps upcoming features to the debt they will touch, and produces a prioritized list scored by (impact times urgency) divided by effort. It tells you which debt items to fix first with a specific payback calculation.
How does it measure velocity impact from tech debt?+
It correlates story completion time against the debt areas each story touched. If stories that touch the auth system consistently take 40% longer than baseline, that is quantified signal. The agent reports both quantitative impact (stories X% slower) and qualitative impact (dev team reports it as painful) for each debt area.
What is the payback calculation?+
For each top-priority debt item, the agent estimates: effort to fix (developer-weeks) versus developer-weeks saved per quarter going forward if fixed. For example, fixing the data layer costs 40 dev-weeks but saves 20 dev-weeks per quarter, so it pays back in two quarters. This lets you make a business case to engineering instead of just saying 'please fix this.'
What data does the agent need to run?+
Jira or Linear with tech debt tickets tagged clearly and linked to features. At least four past sprints with story points and actual completion time. The upcoming feature backlog mapped to affected systems. Engineering input on qualitative pain points. Optionally, deployment and incident data to flag debt that is causing production issues.
How should teams use the weekly output?+
Treat the top three priority items as direct inputs to sprint planning. Engineering should be able to pick the top item and start immediately, because the agent outputs a specific description, the affected systems, and the business case. The Debt Lifecycle section in the report also tells you whether the team is creating new debt faster than it is fixing old debt, which is the signal that matters most long-term.

Comments (0)
Sign in with LinkedIn to leave a comment.
Sign in with LinkedIn