Technical Debt and UNDONE work – An Evil for the Product

Impact

• UNDONE Work – Delayed feedback cycle and the value delivery
• Technical Debt – Increased Total Cost of Ownership (TCO)

You are the Product Owner, and If you have to decide, then which one will you care? To better deal with this situation, let's understand what is Technical Debt and UNDONE work is all about?

What is Technical Debt?

It is a concept from software development. Tech Debt reflects on taking poor technical choices now, i.e., trading-off quality for time and not taking the better approach that would take longer. One can also define it as the long-term consequences of poor design decisions. Sometimes, the tech debt is intentional and sometimes is not. So, what causes it?

Intentional or active Tech Debt

• A conscious choice of taking down quality to hit the market early
  • Maybe to take a competitive edge in the market or
  • To validate an idea for early feedback

Unintentional or passive Tech Debt

• Development team learnings about the problem
• Frequent changes in the team's composition
• An evolving Definition of DONE

There is an analogy for Technical Debt - It's diabetes. There is no cure, but you can only control for a quality life. Should you ignore this, and there are serious consequences. The high technical debt system is highly unstable and unpredictable, which requires more maintenance and hence increases its operating cost. When developing new functionality on the system that carries high technical Debt, due to system failure's unpredictability, it often increases the development cost and hence increases the Total Cost of Ownership.

What is UNDONE Work?

The single most purpose of the Scrum is to create a Potentially releasable DONE increment of the Product, which means the Increment meets the Definition of DONE (DoD). Any work on the Increment that doesn't meet the DoD is termed as UNDONE work of that Sprint.

This UNDONE work makes the Increment not releasable.

The unfinished or UNDONE work is never a part of the Increment and must be placed back to the Product Backlog for the Product Owner to re-order. But what is more hazardous for the Product, is it the Technical Debt or UNDONE work? It isn't straightforward to answer this question as both cause damage to the Product. Technical Debt causes long term damage wherein UNDONE work causes all the time.

Few questions around these are:

• Can the team avoid Technical Debt altogether?
• How much of Technical Debt causes no harm to the Product?
• How to measure the Technical Debt?
• How to control Technical Debt?
• Is all Technical Debt of the Product needs to be cleared?
• Is Technical Debt bad all the time?
• What causes the UNDONE work?
• How UNDONE work impact the feedback loops?
• Are Technical Debt and UNDONE work the same?

These are a few of the questions that I have come across in my sessions, and I shall be answering them one by one in my upcoming blogs. Should you have more questions around this, feel free to post and I will try and answer them.