Skip to main content

"done", "undone" and Technical Debt.

Last post 04:19 am October 20, 2020 by Shekhar Singh
8 replies
02:27 pm September 13, 2019

This is one attempt to bring the terms "done", "undone" and "Technical Debt" together visually. Technical Debt is undone (or potential) work that is implicit / not transparent. What do you think?

 


04:57 pm September 13, 2019

Technical Debt is undone (or potential) work that is implicit / not transparent.

I don't agree with that definition.

Work can be done, but still have technical debt. Consider one example where a team was introducing new technology to solve a particular problem. At the end of the Sprint, they managed to complete the work from a functional perspective, but learned more about the tools and technology that they used as they went along. Towards the end of the Sprint, they realized that some of their decisions weren't that great and should be revised, but there's no time left in the Sprint. The team makes the decision that it's more important to ship the functionality in order to continue to get feedback on it and they will take on the work in the near future. This is "prudent and inadvertent technical debt".

Since the team is aware that they have learned lessons, they may record the need to go back and do further work as a Product Backlog Item. They may quantify the need to do this in terms of the impact of not doing the work - perhaps they learned their approach isn't scalable and need to approach it before scaling or that it will increase the burden on operations and maintenance. This will allow it to be prioritized with the other work.

In this case, the work may meet the team's Definition of Done for both the work as well as the Increment, meaning that the initial scope of work was indeed Done (and new work was identified). It's also transparent since it's visible to the appropriate stakeholders.

I believe that you can say that Technical Debt is potential work, but it doesn't necessarily have to be undone work or not transparent.


08:28 pm September 13, 2019

This is one attempt to bring the terms "done", "undone" and "Technical Debt" together visually. Technical Debt is undone (or potential) work that is implicit / not transparent. What do you think?

I think the Definition of Done should make technical debt transparent. Technical debt may be understood to be the long term consequences of work which fails to meet the Definition.


11:28 pm September 13, 2019

Thanks for you feedback! I was actually trying to share this graphic i made to visualize but can't seem to upload my image. Without the image to elaborate my "definition" from above is indeed flawed.

 

 


09:06 am September 14, 2019

Hello, 

Where can I actually read about Technical debt? 

I am currently preparing for the PSM 1 exam and my trainers advised me to get familiar with the technical debt. 

Thanks! 


05:57 pm September 14, 2019

In my opinion your assessment is missing something. 

Consider these things that I interpret to be technical debt:

  • Bug found in Production by an end user
  • Upgrades to third party components 

Both of those would be transparent to everyone involved in the creation/maintenance of the product.  They should be made transparent to the stakeholders of the product by those involved in the creation/maintenance of the product. @Thomas Owens gives a perfect example and @Ian Mitchell provides a great way of recognizing technical debt.

I actually make an effort to avoid the term technical debt.  In my view, everything in the Product Backlog is an opportunity to provide value. So anything that impacts value should be visible in the Product Backlog.  Everything in the Product Backlog has 2 types of value.  Negative value as long as it exists in the Product Backlog and positive when it is delivered to the stakeholders. Yes, even an enhancement or new feature has negative value if it hasn't been delivered. And yes, fixing a bug or upgrading third party components provide positive value to the stakeholders. The Development Team are the ones best suited to provide the information for a technical debt type item to include it in the Product  Backlog. I know my view is different but by avoiding the term technical debt I have found that it has been easier for people to see everything on the same level.  A few of my Product Owners have even said that it makes ordering technical debt type items higher in the Product Backlog as the value is easier to determine and align with other work.


12:13 am September 15, 2019

@velislava, there are many resources on technical debt here.


07:33 am September 15, 2019

Thank you, Eric, I will take a look today! 

Have a lovely Sunday all :)


04:19 am October 20, 2020

Technical debt describes deferred, necessary work also it includes those internal things that you choose not to do now, but which will impede future development if left undone. This includes deferred refactoring. Technical debt decisions are made based on real project constraints. For more in-depth understanding visit this blog. https://bit.ly/3jghOnb


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

Please note that the first and last name from your Scrum.org 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. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org 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 Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.