Project Management and Technical Debt

Added to Technology

by Tom Grant and Declan Whelan

Contributors: Thierry Coq, Jean-Pierre Fayolle, Jean-Louis Letouzey and Dan Sturtevant

The adage, "Act in haste, repent at leisure," definitely applies to technical debt. People under deadline pressure take shortcuts, which is one of several ways in which project management is a key determinant of technical debt. Project management is also important in other ways. For example, a realistic plan takes into account the impact of technical debt. A superior plan sets aside time to address technical debt.

As discussed in, Introduction to the Technical Debt Concept, the concept of technical debt is quite simple. However, when dealing with technical debt, you have a wide array of options for how to proceed. Therefore, it is important to know the full menu of these options, so that you can make informed selections among them. Whichever you choose, the general rule of thumb should always be, Avoid creating technical debt whenever possible.

Agile project management provides many opportunities to deal with technical debt. Here are some mechanisms you can consider in your projects.

Factor technical debt into release-level activities.

  • Alignment between business and technical concerns. Incurring technical debt allows you to release quickly today at the cost of the slower delivery in the future. Therefore, your approach to technical debt should be clearly articulated and negotiated to balance business outcomes over the near and and long term.
  • Working agreement. The team should have a working agreement that includes technical debt concerns. For example, you could decide to have a list of 10 rules, detected by Static Code Analysis that the team will always adhere to. The agreement could include mentoring, pair programming or other practices for avoiding, measuring or dealing with technical debt.
  • Short-term investment for long-term improvement. When doing long-term planning, beyond the iteration, you need to ask the question, "How do we increase long-term productivity?" The answer includes short-term investments in reducing technical debt.
  • Static code analysis. You may want to include, in your plans, time needed to run a static code analysis tool, as a one-off effort to establish a baseline if one does not exist. Static code analysis makes technical debt visible in ways that other activities, such as code review, do not.
  • Technical debt epics. Some teams encapsulate technical debt reduction efforts into epic user stories to be achieved within a release. This approach simplifies the planning effort, while helping teams think about the business argument for reducing technical debt (the "so that" part of the story).
  • Technical debt iterations. If technical debt exceeds the level where some regular refactoring or a few technical debt stories can address it, the team may need to dedicate one or more iterations to addressing it. This can be particularly valuable if a new team is working with code built by an earlier team.
  • Experimentation. Although we have provided some estimated costs and benefits of many technical debt remediation measures, your results may vary. Additionally, some measures, such as code review, will vary widely from team to team. Other activities, such as test automation, won't have a direct impact on technical debt, but may have powerful second-order effects on the team's ability to deal with debt. Therefore, we urge that you plan for experimentation with these measures.
  • Promotion of successful experiments. Of course, the whole point of experimentation is to apply the results. If you find, for example, that implementing continuous integration gets team members to pay better attention to the state of the code, then you need to set aside time to implement the CI tools and practices.
  • Education. Schedule time to educate people outside of the team about the value of your technical debt-reducing activities. Exercises like the game Dice Of Debt can make a powerful impression in a short amount of time.

Include technical debt consideration in iteration-level activities.

  • Code coverage. Code coverage is important, and not just for catching defects. The tests provide additional information about the intended behavior of the code, and the testing paths may reveal excessive complexity and other technical debt patterns. Consider tracking code coverage at each iteration and focus on having the coverage trend upwards over time. Avoid having absolute code coverage goals (such as 90%).
  • Cost. Measure the amount of overhead that technical debt imposes in your iterations. This could be as simple as, “What percentage of your time do you spend unproductively due to technical debt?” You can trend this measure to visualize the impact of technical debt.
    • Overhead. Technical debt makes it harder for teams to address issues, as part of the regular overhead that constrains the amount of time available to implement new stories. You can make a rough estimate of how much harder it is to address defects and other issues, as a percentage of the regular overhead imposed on the team. For example, you might estimate that time spent on addressing defects in production would drop from 30% to 20%, if you took the time to refactor the code.
    • Velocity reduction. Technical debt also makes it harder for teams to implement new stories. You can make a similar rough estimate of how much easier it would be to implement a story, if you addressed the major sources of technical debt in the code. For example, you might say that the estimate for a story would be 8 story points instead of 13, if you eliminated the code duplication and poor error handling that plagues the code.
  • Developer happiness. As “How happy are you working in the code base?” Often developer happiness, and productivity, will drop if they can’t work effectively in the code due to technical debt. You can trend this measure.
  • Refactoring. When estimating stories be sure to include effort for any refactoring.
  • Technical debt stories. You may want to allocate a percentage of the team velocity for technical debt stories.
  • Slack. Maintain enough slack that, if time is available, developers can use it for refactoring.
  • Mentoring. Set aside time to teach other developers how to prevent technical debt. Consider pair programming or mob programming to promote deeper discussions around good technical practices.
  • Flow. Identify, within the iteration, whether technical debt-created impediments to flow exist (for example, only one person on the team can fix the code, because only that person can understand how it works).
  • Static code analysis. You may want to include static code analysis to chart overall progress towards reducing technical debt.
  • Retrospectives. You may want to facilitate a retrospective on technical debt and explore how it impacts the team and review ideas, perhaps some from this paper, on decreasing the technical debt in your code.

Consider technical debt when implementing user stories.

  • There is a never a good reason to knowingly write bad code! Enough said.
  • Code review. Prevent technical debt by and deterring intentional technical debt by having code reviews. You may want to add this to your Definition of Done or add a “Review” column in your task board.
  • Definition of done. Your definition of done can help avoid and reduce technical debt. Elements like required code coverage and code review are examples of injecting the discipline, at a story level, needed to prevent technical debt.
  • Definition of ready. The impact of technical debt is more severe the larger the code base gets. Having a clear definition of ready for new stories helps the teams build only the code that provides value.
  • Pair/mob programming. Consider pair, or mob, programming to share insights about good and bad code and to promote learning about avoiding and fixing technical debt.
  • Boy Scout rule. Ensure that you always leave the code cleaner than you found it. Technical debt is addressed one line of code at a time. By applying the Boy Scout rule you ensure that you get the biggest bang for your buck with technical debt reduction by focusing improvements on the code that changes the most. Consider including the Boy Scout rule in your team working agreement. (For a good discussion of opportunistic refactoring, see
  • Coding standards. Coding standards should contribute to both the prevention and reduction of technical debt. Teams should agree together on a coding standard and hold each other accountable to it. You can use the [spreadsheet] as a starting point for identifying coding standards that have an effect on technical debt. Over time, the team can tune the coding standards to improve their ability to deal with technical debt.
  • Making technical debt visible. To keep focused on technical debt while coding it can be helpful to use tools that make the quality of the code visible. To build this kind of micro-feedback loop, consider using editors that highlight coding standard violations, or tools that automatically run static code analysis and test code coverage.

Every team has to make decisions about where to start addressing technical debt. Ultimately, you need to create a working agreement within the team that covers how you assess and resolve technical debt. Not every team or project is the same, so you must exercise discretion about which clauses to put into this working agreement. And of course, it is prudent to have a pragmatic working agreement that is doable today and evolves over time.

For your convenience, the following chart can be your checklist for deciding which gets immediate attention.


About the Author

Jean-Louis Letouzey is the author of the SQALE method for managing technical debt. Jean-Louis consults to the world’s leading organizations for the implementation of corporate solutions for managing technical debt. He is also frequently embedded in due diligence teams for assessing the technical debt of the acquired software. Jean-Louis is a frequent technical speaker at international conferences. He leads the Technical Debt Initiative of the Agile Alliance

Declan Whelan, Declan is an agile consultant, co-founder of Leanintuit and a director at the Agile Alliance. Declan works with organizations to improve their products and services through agile and lean practices. His personal mission is to change the conversation around technical debt. Rather than viewing is a technical problem to be fixed we need to view it as valuable feedback of the health of our organizations. We can use these health checks to improve our product and service delivery.

Thierry Coq is a Principal Consultant and Surveyor in Systems and Software Reliability (SSR) at DNV GL (merger of “Det Norske Veritas” and “Germanischer Lloyd”). He is a Systems and Software Architect, Functional Safety Professional, Project Manager and Process Appraiser. He is and has been involved in large multi-site projects, in different industries: Aerospace, Nuclear, Automotive, Energy and Maritime. He has a drive on improving organizations’ and project teams’ processes efficiency and speed with a focus on reliability and safety, with an excellent understanding of deep technical issues. He is a co-author of the Integrated Software-Dependent System (ISDS) Recommended Practice and Offshore Standards published by DNVGL. He has participated in the construction of the SQALE software quality assessment method with Jean-Louis Letouzey. He is the author of the book “Méthodes et informatique: Réussite du projet informatique par la méthode”, Lavoisier, 2012 (“Making software projects successful with method”) and has published many articles. Previously, he was new technology manager, project manager and engineer at engineering firms Q-Labs, Dassault Systems and CISI.

Jean-Pierre FAYOLLE is a French expat, located in Madrid and working as a freelance consultant in Software Quality and Customer Success Management. Prior to this, Jean-Pierre was Technical Director or Head of Applications and Development for different software companies or service providers, with ample experience in consulting and implementing software solutions for large international companies. Jean-Pierre holds a Master of Advanced Studies in Business Administration from the University of Lyon (France) and in Computing Management from the University of Quebec (Canada). He is the founder and main author of the blog Qualilogy (, about Software Quality.

Tom Grant is an independent consultant (GameChange LLC) who help clients break through the barriers to successful software innovation. In his practice, he combines Agile, Lean, and serious games to change the rules of innovation when they're not working as well as they could. Tom has worked with a wide variety of clients, from Fortune 100 companies to start-ups, from IT to software companies.Some of Tom's areas of specialization include technical debt, Lean and Agile, management and leadership, Agile in highly regulated industries, requirements, tools, and frameworks. Tom's great passion is using serious games in Agile to get better customer insights, test strategies through simulated outcomes, adopt new practices and principles through experiential learning, and make smarter decisions.Tom is a contributor to the Agile Alliance's working group on technical debt. Previously, Tom has worked as practice director at Cutter Consortium, as a consultant at Net Objectives, and an analyst at Forrester Research. A native Californian, Tom now lives in Washington, DC.

Dan Sturtevant is the CEO of Silverthread, Inc., a leading provider of tools and services that help organizations regain control of software systems and drive results by focusing on design quality and its long term impact on long-term maintainability, agility, and cost. Based on R&D done at MIT and Harvard Business School, Silverthread helps organizations build insight and systematically improve so that systems can be delivered on time with high quality, and so they remain adaptable in the face of change. Dan earned his Doctorate from MIT, where he measured development productivity, quality, and risk in complex codebases. Prior to cofounding Silverthread, Dan spent many years in the software field building supercomputers used in aeronautical design simulation and developing defensive cyber warfare systems.

Agile Alliance is a nonprofit organization with global membership, supporting and serving the Agile software community since 2001. We support people who explore and apply Agile values, principles, and practices to make building software solutions more effective, humane, and sustainable. We share our passion to deliver software better every day.

This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.