Technical Debt & Maintenance Simulator

Sprint Capacity Allocation

Feature development 50%

Refactoring 30%

Bug fixing 20%

Total: 100% of team capacity

Simulation speed 1.0×

Team Health

Technical debt

Velocity

10.0 pts

Open bugs

Sprint

How it works

Each of the 64 boxes is a module in a simulated codebase. Height = that module's local technical debt, colour = its local bug density (green → amber → red). Every sprint the team's capacity is split three ways by your sliders (normalised to sum to 100% regardless of the raw values):

velocity(t) = baseCapacity / (1 + debtIndex/40)      // diminishing returns from debt
featureOutput   = velocity × featureFrac
refactorEffort  = baseCapacity × refactorFrac
bugfixEffort    = baseCapacity × bugfixFrac

debtIndex  += featureOutput × 1.6 − refactorEffort × 2.2       (clamped 0–100)
bugSpawn    = debtIndex × 0.05 × (0.5 + 0.5 × featureFrac)
bugBacklog += bugSpawn − bugfixEffort × 1.1                    (clamped ≥ 0)

Feature development ships story points but raises debt, and raises it faster the more of it you do while debt is already high (more bugs slip in).
Refactoring burns capacity with no visible output but pays debt down, which is what keeps velocity from decaying.
Bug fixing drains the open-bug backlog; ignore it and bugs compound because higher debt spawns bugs faster.
Push feature work to 100% and watch velocity collapse over ~15–20 sprints as debt saturates near 100 — the classic "we can't ship anything anymore" spiral. Balance the three to hold a steady state instead.

Sprint 0

Low debt / healthy module Moderate debt High debt, bug-prone

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.