
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.
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.
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.