# A Practical Guide to Handling Technical Debt in Scrum | LinearB Blog > In this article, we’ll look at what our options are to tackle technical debt in scrum and still deliver business value at the sprint’s end. _This is a markdown rendering of a live HTML page on linearb.io, generated for AI/LLM consumption — it is not a markdown-only site. To get the full HTML page instead, request this URL with an explicit `Accept: text/html` header (no wildcard, no markdown preference)._ [Blog](https://linearb.io/blog) / A Practical Guide to Handling Technical Debt in Scrum # A Practical Guide to Handling Technical Debt in Scrum ![Photo of Peter Morlion](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/logo-mark-lg?_a=BAVMn6ID0) By [Peter Morlion](https://linearb.io/blog/handling-technical-debt-in-scrum#peter-morlion) | July 6, 2021 ![technical_debt_f802af3ccc](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/technical_debt_f802af3ccc?_a=BAVMn6ID0) Is your development team complaining about technical debt? Or do you suspect that technical debt is a problem in the code? If you’re working with scrum, you might wonder how you can address the technical debt while still staying true to the scrum framework and agile principles. In this article, we’ll look at what our options are to tackle technical debt and still deliver [business value](https://www.enov8.com/blog/devops-void-value-stream-mapping/) at the end of the sprint. ## Defining Technical Debt Before we can even begin to handle our technical debt, we need to know what we’re talking about. There are many definitions of technical debt. Wikipedia has a good one: > Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer. > > [Wikipedia](https://en.wikipedia.org/wiki/Technical%5Fdebt) So this means that we can take shortcuts when writing code to deliver faster. But these shortcuts often mean bad design and code that are harder to work with in the long run. At some point, we need to improve that code (pay down the debt) instead of making things worse (taking on even more debt). A piece of code might be considered bad and technical debt by one developer, while another developer might regard that code as good. So we need a way of not only defining technical debt but also identifying it in our projects. However, let’s take a step back and consider if this is even an issue we should care about. ## Should the Product Owner Even Care? Scrum defines several roles with distinct responsibilities. The product owner represents the client and is responsible for managing requirements with business value. The development team is responsible for the technical implementation. Some people are of the opinion that this means the product owner shouldn’t care about technical debt and that it is purely an internal matter for the development team. This means the team must factor in technical debt when they make their estimates. Others would say that the work is there and you should make it visible. [The Agile Manifesto](https://agilemanifesto.org/) chooses “individuals and interactions over processes and tools,” so we should be able to have a conversation with the product owner about our technical debt. Scrum is a framework within the agile ecosystem. We can adapt scrum to our team, as long as we stay true to the intentions of agile software development. So with that said, what are our options to address technical debt in a scrum team? First, we need to know how bad the situation is. ## Identify Your Technical Debt There are [different ways](https://linearb.io/blog/how-to-measure-technical-debt/) of pinpointing technical debt. Automated tools will show you problematic code and even suggest fixes. But they might not catch all issues. Probably the first source of knowledge will be the ones working in the code. ### Talk With the Team Since scrum is a methodology within the agile world and the Agile Manifesto states to prioritize individuals and interactions, get a conversation started with the team about technical debt. How do they feel about it? How bad is it? What do they think needs to be done? A good conversation, without finger-pointing, will give you good insights into team dynamics, emotions, causes, and possible solutions. ### Make Stories in Your Issue Tracker A traditional approach would be to have the team create issues in the issue tracker they’re using, like Jira. Maybe add a tag to the item so you can list all technical debt tasks at once. For teams that choose to handle technical debt without their product owner knowing, this is their technical debt register. The development team is responsible for tracking, prioritizing, and discussing these items. If the product owner is in the loop, these items can be added to the product backlog so that the product owner can prioritize together with the team. Often, though, product owners are under pressure to deliver business value, so technical debt stories or tasks may be pushed back. ### Wall of Technical Debt The Wall of Technical Debt is a technique that should be credited to [Mathias Verraes](https://verraes.net/2020/01/wall-of-technical-debt/). It’s an interesting way to show stakeholders how much time a team is spending on technical debt. In short, the team puts sticky notes on the wall identifying areas in the code they feel are blocking them and should be improved. On these notes, the team adds how much time they wasted because of the technical debt and how much time they estimate it would take to fix the issues. After a while, both the team and the product owner can see where the team is losing time and where the low-hanging fruit is (e.g., simple fixes that will save a lot of time). ### Metrics There are many metrics that can point you to technical debt, like code coverage and cyclomatic complexity. Those are developer-centric metrics, and teams are encouraged to use them. LinearB also contains useful metrics. LinearB pulls in data from a variety of sources that the development team is already using, without any extra work for them. The work breakdown is especially interesting when considering technical debt: ![work breakdown](https://assets.linearb.io/uploads/work-breakdown.png) “New work” means adding new features. “Refactor” refers to changing old code, while “rework” means changing code that was only written in the last few days. These numbers can indicate the balance between innovation and technical debt. These are just numbers, and there will always be [refactoring](https://linearb.io/blog/refactoring-in-agile/) and rework going on. But they can be the basis for a conversation with the team. LinearB also has a section on metrics where you can dig deeper: ![linearb metrics](https://assets.linearb.io/uploads/Work-Breakdown-1.png) Two other interesting metrics are [cycle time](https://linearb.io/blog/cycle-time/) and coding time: ![cycle time](https://assets.linearb.io/uploads/cycle-time.png) ![coding time](https://assets.linearb.io/uploads/cycle-time-coding-time.png) The longer these times are, the harder the team is finding it to finish features. Of course, for the real causes, you should have an open conversation with the team (people and interactions, remember?). But it can point to technical debt. ## Addressing Technical Debt With Scrum So now that you’re measuring and identifying areas of technical debt in the code, what options do we have in scrum to address it? ### Dedicated Stories One possibility is to create stories dedicated to technical debt. One or more specific areas could be added to the story, and tasks can then be defined. The team can make their estimates, and the product owner can decide when to add the story to the sprint. This is, of course, assuming that the team is open about technical debt and that the product owner has a say in when to fix it. There is a risk that these stories will be postponed because features with business value are prioritized. In my experience, this is not a bad option, especially for larger areas of technical debt and with mature teams that have a good relationship with their product owner. In such cases, this can definitely work. ### Continuous Refactoring Continuous refactoring is purely an internal affair for the development team. When a developer works in a piece of code for a new feature or a change request, they should see if any of the existing code can be improved. Maybe some of it was identified as problematic earlier. If so, then now is the time to improve it, however small, as part of the work for the new feature. I strongly believe this is something the team should be doing, whether using scrum or not. ### Dedicated Sprints Sometimes, teams advocate for a sprint dedicated to technical debt, but I advise against it. Addressing technical debt won’t provide business value at the end of the sprint. This makes such a sprint clash with the ideas behind scrum—that you should deliver business value to the product owner. ### A Fixed Amount of Time Per Sprint Scrum aims to stop estimating and counting in hours, hence the idea of story points. Allotting a fixed amount of time can seem to clash with this idea. This approach lacks a definition of the work the developers will take on. And what if the developer starts working on something that takes more time than allotted? Or less? These are questions that might push you back to estimating in hours, which scrum wants to avoid. ## LinearB Can Help Even though the Agile Manifesto prefers human interaction, it doesn’t rule out tools entirely. The nice thing about LinearB is that it won’t bother the developers. They can keep using the tools that make them productive (like Jira and Git) while LinearB will surface the [metrics that interest product owners, CTOs, and VPs of engineering](https://linearb.io/engineering-metrics/). Also, LinearB won’t look at metrics for individual developers but at the team as a whole. This avoids a toxic blame culture or stack-ranking environments that lower morale and productivity. If you decide to describe your technical debt in stories—for example, in Jira—you can put those in a separate category and LinearB will show you how much time you’re investing in them: ![investment profile](https://assets.linearb.io/uploads/Investment-Profile.png) You can also see these numbers over time, spread across your iterations. ## Scrum and Technical Debt Scrum definitely leaves room for addressing technical debt in a way that suits your team best. It can be an internal affair of the development team, but it might also be something that can be openly discussed, using tools to identify and measure the technical debt. Making things explicit will empower product owners and developers to pay down the debt and improve the quality of the code. This in turn makes the code more fun to work in and makes developers more productive, enabling them to deliver more business value at the end of each sprint. ## Improve developer productivity with LinearB Find us on [](https://www.linkedin.com/company/linearb) [](https://devinterrupted.substack.com/) ## Your next read [![Cover image for AI as a value multiplier: a human-centric approach to engineering leadership](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Blog_Servant_Leadership_2400x1256_0cfd4e2a0c?_a=BAVMn6ID0)](https://linearb.io/blog/ai-as-value-multiplier-human-centric-leadership) Leadership [AI as a value multiplier: a human-centric approach to engineering leadership](https://linearb.io/blog/ai-as-value-multiplier-human-centric-leadership) Super.com's Matt Culver explains why AI should be used as a value multiplier, not a cost-cutter, advocating for a human-centric approach to engineering... [![Cover image for The Moneyball approach to engineering leadership](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Blog_Balancing_Technical_Depth_2400x1256_b56d93a733?_a=BAVMn6ID0)](https://linearb.io/blog/moneyball-approach-engineering-leadership) Leadership [The Moneyball approach to engineering leadership](https://linearb.io/blog/moneyball-approach-engineering-leadership) Rethink engineering leadership with Transcend's Minh Nguyen and learn how to balance hands-on technical work with strategic leadership, communicate with a... [![Cover image for Strategic lessons from Google on improving engineering teams](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Blog_Strategic_Lessons_From_Google_2400x1256_1_cd28b7242d?_a=BAVMn6ID0)](https://linearb.io/blog/strategic-lessons-google-engineering-teams) Leadership [Strategic lessons from Google on improving engineering teams](https://linearb.io/blog/strategic-lessons-google-engineering-teams) Learn key lessons from Google on aligning engineering with business goals, boosting developer productivity, and building sustainable team culture. ## Structured data _Machine-readable metadata (JSON-LD) embedded in the page for search/AI context — not content rendered on the page itself._ ```json { "@context": "https://schema.org", "@type": "Organization", "name": "LinearB", "url": "https://linearb.io", "logo": "https://assets.linearb.io/image/upload/v1715628027/logo-mark-lg.svg", "description": "LinearB is the engineering productivity platform that helps engineering leaders prove AI is improving throughput without sacrificing delivery confidence, flow efficiency, or developer experience.", "sameAs": [ "https://www.linkedin.com/company/linearb" ], "award": [ { "@type": "Award", "name": "LinearB is a Leader in the 2026 Gartner® Magic Quadrant™ for Developer Productivity Insight Platforms", "dateAwarded": "2026", "awardedBy": { "@type": "Organization", "name": "Gartner®" } }, { "@type": "Award", "name": "Great Place to Work Certification", "dateAwarded": "2025-2027", "awardedBy": { "@type": "Organization", "name": "Great Place to Work" } }, { "@type": "Award", "name": "America's Best Startup Employers 2025", "dateAwarded": "2025", "awardedBy": { "@type": "Organization", "name": "Forbes Magazine" } } ], "hasCertification": [ { "@type": "Certification", "name": "SOC 1 Type 2" }, { "@type": "Certification", "name": "SOC 2 Type 2" }, { "@type": "Certification", "name": "GDPR Compliance certification" }, { "@type": "Certification", "name": "ISO 27001" } ] } ``` ```json { "@context": "https://schema.org", "@type": "Article", "headline": "A Practical Guide to Handling Technical Debt in Scrum", "url": "https://linearb.io/blog/handling-technical-debt-in-scrum", "author": { "@type": "Person", "name": "Peter Morlion" }, "datePublished": "2021-07-06T08:26:31.000Z", "dateModified": "2021-07-06T08:26:31.000Z", "image": "https://assets.linearb.io/image/upload/v1720000000/technical_debt_f802af3ccc.jpg", "publisher": { "@type": "Organization", "name": "LinearB", "logo": "https://assets.linearb.io/image/upload/v1777485755/linearb-logo-2026.png" }, "description": "In this article, we’ll look at what our options are to tackle technical debt in scrum and still deliver business value at the sprint’s end.\n" } ``` ## More on linearb.io ### Top navigation - [Book a Demo](https://linearb.io/book-a-demo) - [AI Code Reviews — Catch security risks, bugs, and spec mismatches](https://linearb.io/platform/ai-code-reviews) - [AI & Productivity Insights — See how AI tools affect cycle time and delivery speed](https://linearb.io/platform/ai-developer-productivity-insights) - [Measure AI Impact — Track AI adoption and tie it to delivery outcomes](https://linearb.io/use-case/measure-ai-impact) - [MCP Server — Chat with your data to spot patterns and boost output](https://linearb.io/platform/mcp-server) - [Resource Allocation — Cost initiatives and shape your investment strategy](https://linearb.io/platform/resource-allocation) - [Cost Capitalization — Capitalize engineering costs with audit-ready reports](https://linearb.io/platform/cost-capitalization) - [Dev Team Management — Set targets and tie throughput to business outcomes](https://linearb.io/platform/goals-and-reporting) - [DevOps Workflow Automation — Policy-based PR routing, approvals, and tests](https://linearb.io/platform/ai-workflow-governance) - [AI Powered Support — Unify AI and human code delivery in one clear view](https://linearb.io/use-case/ai-powered-support) - [Optimization — Surface friction with feedback and MCP insights](https://linearb.io/platform/developer-experience) - [Reporting — Spot what's working and what needs attention](https://linearb.io/use-case/measuring-developer-experience) - [Surveys — Turn developer feedback into actionable signals](https://linearb.io/platform/developer-surveys) - [Platform overview](https://linearb.io/platform/overview) - [Register now](https://linearb.io/event/engineering-productivity-gap) - [Customers](https://linearb.io/customers) - [Pricing](https://linearb.io/pricing) - [Why choose LinearB — Explore your data. Measure performance. Act to improve it.](https://linearb.io/why-linearb) - [APEX framework — The operating model for AI-era engineering teams](https://linearb.io/resources/apex-framework) - [Anti-FAQ — The questions other vendors won't answer](https://linearb.io/why-linearb/anti-faq) - [Security — Enterprise-grade compliance and zero code access](https://linearb.io/security) - [Build vs. buy — The hidden cost of building it yourself](https://linearb.io/resources/build-vs-buy) - [Dev Interrupted Podcast — Conversations with engineering leaders](https://linearb.io/dev-interrupted/podcasts) - [Reports & Guides — Deep dives on productivity and delivery](https://linearb.io/resources) - [Webinars — Expert sessions on productivity and AI](https://linearb.io/resources?category=workshops) - [Metrics Benchmarks — See how your engineering org stacks up](https://linearb.io/resources/software-engineering-benchmarks-report) - [Blog — Product updates and practical insights](https://linearb.io/blog) - [Help Center — Documentation, setup, and support](https://linearb.helpdocs.io) - [API Docs](https://docs.linearb.io/api-overview) - [Status](https://www.linearbstatus.com/) - [Integrations](https://linearb.io/integrations) - [LinearB is a Leader in the 2026 Gartner® Magic Quadrant™ for Developer Productivity Insight Platforms](https://linearb.io/resources/gartner-magic-quadrant-dpi-platforms-2026) - [Sign in](https://app.linearb.io/login) - [Enterprise](https://linearb.io/solutions/enterprise) - [Contact](https://linearb.io/contact-us) - [About us](https://linearb.io/about-us) - [Careers](https://linearb.io/careers) - [Service agreement](https://linearb.io/services-agreement) - [Privacy policy](https://linearb.io/privacy-policy) - [DPA](https://linearb.io/data-processing-agreement) - [Security FAQ](https://linearb.io/security-faq) - [Substack](https://devinterrupted.substack.com/) ### Footer _Additional links from the site footer, not repeated from the top navigation above._ - [GitHub](https://github.com/linear-b) - [LinkedIn](https://www.linkedin.com/company/linearb) - [Twitter](https://twitter.com/LinearB_Inc)