The longer-term implications of poor design decisions are referred to as technical debt and documented in product backlog. It’s similar to any other debt in that there should be a clear understanding of why it was incurred, as well as how and when it should be paid back.
“When it comes to getting out of debt, there are no quick cuts” – Dave Ramsey
It is occasionally regarded to be worthwhile. “Bad design decisions,” for example, could be made for the sake of expediency. Continuing to use an unscalable architecture may allow for a delivery to a Product Owner that would otherwise be unattainable if a redesign were to take place right now. There will be long-term expenses associated with delaying remediation because the design will become more difficult to rework the longer it is in place and used.
That’s plainly a debt because we’re borrowing time from the product’s future, which must be repaid-with interest. However, given the benefit of making that early delivery, the decision to take on this debt may be deemed appropriate and worthwhile.
We discussed how a “technical debt register” might assist a Development Team in making educated judgments about whatever technical debt they chose to incur in a previous post. The register will make the debt visible and allow the team to handle it at the appropriate technical level, allowing it to be resolved. There are, of course, various options for a Development Team to manage their debt.
When only a small amount of money is needed, team members may be able to keep track of what needs to be paid totally in their minds. In the case of architectural refactoring, the need for redesign may be self-evident, as it may be a daily annoyance for those developers.
Another option is to document technical debt in the Product Backlog. To make this work, the Product Owner would obviously need a high level of technical knowledge. He or she must be able to comprehend the debt’s nature and impact on value, as well as prioritise such entries in comparison to other Product Backlog Items. In the first instance, the Product Owner would have to be willing to take on this debt.
It’s crucial to note that the Product Backlog isn’t a place where the Development Team may deposit their technical debt. The Development Team owns the Product Owner and the stakeholders the PO represents this debt. They anticipate and believe that the Development Team will always do the right thing on a technological level. If the Development Team believes it is the correct thing to do in a specific situation, they have the right to incur technical debt. That debt, on the other hand, cannot be passed off to the Product Owner as more “scope” to be prioritised and negotiated.
Some cases of technical debt may be examined by the Product Owner for possible placement on the Product Backlog if doing so allows for better debt management in terms of product value, but others may not. A Product Owner is not obligated to accept a Development Team’s debt in Scrum. Scrum roles are intended to work together, but they also have their own obligations and duties. The Product Owner, as a responsible partner with specific concerns, may or may not be interested in covering instances of technical debt incurred by the Development Team.
What does this mean for the Product Backlog, though? According to the Scrum Guide, this object is supposed to be the “single source of requirements.” Isn’t it consequently vital to keep track of technical debt? After all, technical debt indicates that there is still work to be done.
Let’s not forget that each Product Backlog Item requires an estimate. This means that the Product Backlog should always take into account the cost of resolving any and every technical debt. If this is not done, a false picture of how much more money needs to be invested before a product reaches maturity would emerge.
Only a small amount of the work will be visible, similar to an iceberg, while the requirement for extra effort will be buried and unquantified beneath the surface. Transparency regarding the amount of work that is really believed to remain is required. That is a fact that should always be visible in the Product Backlog. Estimates for the Product Backlog should always include the expense of repaying technical debt in a timely manner. The Product Backlog, on the other hand, will not always describe the nature of the technical debt that is captured in those estimations. “Refactor this,” “test that,” and “replace method X with Y” are unlikely to appear on a Product Backlog.
Most Product Owners will struggle to prioritise such work in comparison to other Product Backlog Items if they even comprehend it at all. They might not be willing to take on this debt on their own to manage it. This debt is a technical issue that the Development Team could better control through the use of a technical debt registry.
However, in order to give transparency over the work that genuinely remains, the estimations on the Product Backlog must account for the scale of any such debt thus recorded. The cost of debt elimination must be factored into any estimates supplied for completing any additional work that the Product Owner has specified. In short, technical debt may not accurately define the breadth of a project, but it always has implications.
Author :
