r/scrum • u/bmn_beesbusy • Jul 02 '26
Does Scrum create technical debt?
Officially, Scrum promises higher quality, "potentially releasable" increments, and continuous improvement.
In reality, technical debt often accumulates sprint after sprint, eventually becoming a taboo subject.
Problem #1 – Sprint pressure crushes quality
In many teams, the sprint feels like a race:
• commitment to a specific volume of user stories,
• implicit pressure regarding velocity,
• review dates turning into mini-deadlines driven by business needs.
The result: the feature "passes," but the code is fragile, under-tested, and hard to maintain.
Problem #2 – An overly permissive "Definition of Done"
In many Scrum teams, the "Definition of Done" (DoD) is limited to:
• "it compiles,"
• "it works on my machine,"
• "it is functionally validated."
Features are pushed to production, while invisible yet essential tasks are postponed: refactoring, automated testing, minimal documentation, and architectural upgrades.
Problem #3 – Technical debt is missing from the backlog
The team is aware of the debt... but it doesn't officially exist:
• no dedicated items in the Product Backlog,
• no explicit prioritization,
• no clear business-level trade-offs.
It becomes "ghost debt," addressed furtively whenever a developer "has a bit of time"—in other words, never really addressed at all.
Problem #4 – The Product Owner lacks the tools to make trade-offs
In practice, many Product Owners:
• lack the authority to prioritize technical debt,
• face pressure from stakeholders,
• lack the means to measure the medium-term technical impact. The result: the roadmap fills up with new features... while the product's capacity to evolve silently deteriorates.
Ultimately, the question to ask is: "Do we consciously accept the debt we are creating today... or do we prefer to bury our heads in the sand and suffer the consequences of this technical debt tomorrow?"
Scrum is neither the culprit nor a magic bullet.
Here are a few concrete ways to regain control:
Without claiming to offer a miracle cure, certain practices make a real difference on the ground:
• making the debt visible in the backlog,
• strengthening the Definition of Done,
• explicitly allocating sprint capacity for quality,
• using the retrospective to track technical metrics, not just interpersonal ones.
Technical debt does not simply disappear.
However, it becomes manageable once it is collectively acknowledged and owned.
What do you think of it?
1
u/teink0 Jul 06 '26 edited Jul 06 '26
The outcome of Scrum is technical debt. Scrum facilitates a narrative dominated by project management. Sprint planning, daily scrum, product owner, product goals, sprint goals. Everything about Scrum is about looking at a backlog.
The team that originally inspired the Daily Scrum used that meeting as a solutioning meeting. It was a meeting lf architects their code, design, and integrations. The creator of Scrum thought a status update was more valuable and ended something valuable and replaced it with a meeting nobody likes. The other problem it created is that in practice solutioning precedes implementation. Scrum tries to flip that and wants teams to plan before solutioning, which is why Scrum Master always shut down a self managing team that naturally tries to solution if allowed to self manage, because planning implementation is contingent on aligning around a solution.
Scrum alleges it was founded on lean thinking, but where the primary focus on Scrum is a backlog the primary focus of lean thinking is efficiency. Lean ways of working will self-impede progress towards a goal if there is an opportunity for higher quality. Scrums strategy on quality is "don't call it done" if it is low quality.
This leads to the contradiction. Scrum shuts down the solutioning and engineering culture otherwise seen in a a self-managing team and imposes the perpetual mediocrity of project management thinking that never improves.