Dedicate 20% of each sprint to tech debt
We keep saying we'll address tech debt 'next quarter' and it never happens. Our test coverage is at 47%, we have 200+ Rubocop violations, three deprecated gems with known CVEs, and the deployment process still requires manual steps that should have been automated years ago.
I'm proposing a standing policy: 20% of every sprint is reserved for tech debt. No exceptions, no borrowing against it for features. Teams choose what to work on, but the time is protected.
Comments 6
Counter-proposal: instead of a fixed percentage, require that every PR improves the codebase in some small way beyond the feature. Add a test, fix a linting violation, update a dependency. It compounds over time without needing a formal allocation.
I've tried the 20% approach at two companies. Both times, it quietly eroded to 10%, then 5%, then nothing. The only thing that works is a dedicated team or rotation whose sole job is tech health. Otherwise feature pressure always wins.
The real problem is we don't track tech debt. We say 'we have a lot of tech debt' but there's no backlog, no prioritization, no measurement. Before we allocate time, we need to inventory what exists and rank it by impact.
I'd rather do a dedicated tech debt sprint every 6 weeks than spread it across every sprint. When you do 20% continuously, the work is too fragmented to tackle anything meaningful. A full sprint lets you do real refactoring.
The CVEs are the only urgent thing on your list. Those should be regular work items, not tech debt allocation. Framing security fixes as 'tech debt' is how they keep getting deprioritized.
20% is too rigid. Some sprints we're shipping a critical feature and need all hands. Some sprints we have slack time and could do 40% tech debt. A fixed percentage sounds fair but doesn't reflect reality.
Themes 4
I'd rather do a dedicated tech debt sprint every 6 weeks than spread it across every sprint. When you do 20% continuously, the work is too fragmented to tackle anything meaningful. A full sprint lets you do real refactoring.
The real problem is we don't track tech debt. We say 'we have a lot of tech debt' but there's no backlog, no prioritization, no measurement. Before we allocate time, we need to inventory what exists and rank it by impact.
The CVEs are the only urgent thing on your list. Those should be regular work items, not tech debt allocation. Framing security fixes as 'tech debt' is how they keep getting deprioritized.
I'd rather do a dedicated tech debt sprint every 6 weeks than spread it across every sprint. When you do 20% continuously, the work is too fragmented to tackle anything meaningful. A full sprint lets you do real refactoring.
The real problem is we don't track tech debt. We say 'we have a lot of tech debt' but there's no backlog, no prioritization, no measurement. Before we allocate time, we need to inventory what exists and rank it by impact.
I've tried the 20% approach at two companies. Both times, it quietly eroded to 10%, then 5%, then nothing. The only thing that works is a dedicated team or rotation whose sole job is tech health. Otherwise feature pressure always wins.
20% is too rigid. Some sprints we're shipping a critical feature and need all hands. Some sprints we have slack time and could do 40% tech debt. A fixed percentage sounds fair but doesn't reflect reality.
I've tried the 20% approach at two companies. Both times, it quietly eroded to 10%, then 5%, then nothing. The only thing that works is a dedicated team or rotation whose sole job is tech health. Otherwise feature pressure always wins.
20% is too rigid. Some sprints we're shipping a critical feature and need all hands. Some sprints we have slack time and could do 40% tech debt. A fixed percentage sounds fair but doesn't reflect reality.
Counter-proposal: instead of a fixed percentage, require that every PR improves the codebase in some small way beyond the feature. Add a test, fix a linting violation, update a dependency. It compounds over time without needing a formal allocation.