26 September 2021

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.

Leave a Reply

Your email address will not be published. Required fields are marked *