Skip to main content

Technical Debt, Quality, and Definition of Done

Last post 12:55 am March 8, 2024 by Pierre Pienaar
7 replies
10:38 pm February 24, 2024

Hi everyone. Please in a case where Developers contend with a technical debt due to unforeseen circumstances, what should they do? Can they still deliver the result of the current sprint as an 'Increment' and does this still meet their Definition of Done, considering that the Scrum Guide states that original Sprint Goal does not change and set quality standard does not decrease during a Sprint? Thank you very much.

09:02 pm February 26, 2024

This is a conversation for the whole team.

I think the "by-the-book" answer, based on the Scrum Guide, is that "quality does not decrease". If work doesn't meet the Definition of Done, it "cannot be released or even presented at the Sprint Review". In terms of Martin Fowler's Technical Debt Quadrants, I would express this as a prohibition on all forms of deliberate technical debt - even if it's prudent, you cannot release or demonstrate the work. You cannot necessarily prevent inadvertent technical debt, since you may not know if it exists until later.

However, I'm not sure this is the right choice in all situations. There's a reason why Fowler calls some technical debt deliberate and prudent. Releasing the work or being able to demonstrate it to stakeholders quickly may be more beneficial. If you're going down the wrong path and building the wrong thing, you can stop earlier and change course, perhaps as early as the next Sprint. If you stretch the work out over multiple Sprints because you think it's valuable but doesn't meet the team's Definition of Done and still has known technical debt, you could spend twice as long or longer and even perhaps build upon incorrect work.

I would expect a conversation between the Developers and the Product Owner, perhaps facilitated by the Scrum Master, to come to the right decision to balance quality with fast feedback loops. There's a balance between the fast feedback loop and investing time to quickly pay down technical debt that the team knows exists in the system and bringing quality back to desired levels fast.

10:24 pm February 26, 2024

Thank you a lot for your insightful feedback, Thomas!

11:58 am February 27, 2024

Is this technical debt created from the past, or is this something created in the current Sprint?

If it is from the past and not created in the current Sprint here are the options I've seen teams leverage:

  • Make Tech Debt transparent on the Product Backlog;
  • Team Working Agreement to clean up x% per Sprint;
  • Account for Tech Debt when sizing work and in Sprint Planning;
  • Boy Scout rule: leave the codebase better than when you found it;

If it is something created in the current Sprint because the Definition of Done was weak, leverage the Sprint Retrospective to inspect and adapt the Definition of Done to avoid tech debt in the future. 

If the Definition of Done already includes items such as code reviews, refactoring, code coverage, and other items to catch and remove technical debt, yet it was ignored by the Developers, then the PBIs shouldn't have been added to the Increment. Leverage the Sprint Retrospective to discuss topic.

01:05 am February 28, 2024

Please in a case where Developers contend with a technical debt due to unforeseen circumstances, what should they do? 

Make sure those circumstances are foreseen and dealt with in the future.

  1. Observing a good Definition of Done is the bulwark against technical debt, so firstly the DoD needs improving and honoring. At that point, the Developers will have an Increment they can have confidence in.
  2. Secondly, any technical debt which has been incurred needs to be accounted for on the Product Backlog. It must tell the truth at all times about the total amount of work remaining for the Product. 
  3. Thirdly, the Developers ought to decide a policy for paying off a certain amount of the technical debt every Sprint, until it is drained.

09:48 pm February 28, 2024

Thank you a lot for all the awesome responses. They are enlightening!

10:22 pm March 6, 2024

Navigating technical debt in Scrum requires transparency, prioritization, and unwavering quality. While the original Sprint Goal remains, address debt incrementally. Reflect, adapt, and maintain the Scrum mindset

12:55 am March 8, 2024

My understanding of technical debt is that it is from a decision to follow a design or code in a certain way that isn't sustainable in the long run or will give problems later on like performance issues. Technical debt is not a defect or bug.

The answers above were good. Be transparent etc and log an item to the backlog.

But answering the original question directly, I read the team either created technical debt or technical debt was uncovered that was introduced earlier. Also speaking generally on technical debt as the specific nature of this debt is not known.

Focussing only on the question, "can they still deliver the result of the current sprint as an Increment", I would say yes, it is possible.  Technical debt should imply the system is working, but later on issues will come up. Release the working increment and fix the technical debt in a later sprint.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.