Scrum and Technical practices : Technical Debt

Technical Debt definition

• Technical Debt is the typically unpredictable overhead of maintaining the product, often caused by less than ideal design decisions, contributing to the total cost of ownership.

Technical Debt origin

• Technical Debt comes from making bad technical decisions and is the eventual consequences of poor technical choices.

Technical Debt discovery purpose

• The Team should pay it back continuously.
  • If the Team does not pay back, it will decrease the development speed over time.
  • Although its measurement is hard its growth would lead to wrong assumptions about Increments delivery and even might prevent creating the releasable product.

Technical debt consequence

• A Technical debt reduces Transparency :
  • It misleads the Product Owners, Scrum Masters and even the Developers with their assumptions about the “Current state” of the System.
    • For example, if Product Backlog item A is assumed to be completed in a day, it might take three days for it to complete, because of unseen bad code or Technical Debt.
  • The Product becomes more unstable, as more functionality / features added over bad code (or existing technical debt).
    • For example, suppose that the team decided to delay some important refactoring to facilitate an early release.
      • Technical debt starts to accrue at that point, and it may not map cleanly to specific items on the Product Backlog.
      • It is far more likely to impact components which cross-cut a range of features.
  • Moreover, if the necessary refactoring is significant it could impact the entire product, and it could affect features in uneven ways.

Technical debt practice

• Technical debt comes from making bad technical decisions and is the eventual consequences of poor technical choices.
  • The Team should pay back it continuously.
  • If the Team does not pay back, it will decrease the development speed over time.
  • Although its measurement is hard its growth would lead to wrong assumptions about Increments delivery and even might prevent creating a releasable product.
• On the other hand, each Sprint purpose is creating at least one releasable business functionality.
• So stopping it to pay the technical debt back is not a proper policy.

Technical debt types

• Technical debt types are as following :
  • Implementation debt :
    • Bad coding
  • Architecture debt :
    • Bad architectural principles, design rule violations, lacking design patterns
  • Test debt:
    • Missing test cases, lack of test coverage, lack of test automation
  • Documentation debt:
    • Missing documentation, poorly updated documentation, low traceability between documentation and implementation

Scrum Testing

The Scrum framework

More informations for the Scrum PSD certification here.

Updated : 01/10/2021