Scrum emphasizes that all members of the team must know the technical debt of the product. But sometimes, this debt is not tangible as a simple to-do list. Should we register it as another task in the product backlog to review in another sprint? Or should we put it in some document related to this product, so the team can actually know what tasks should be treated later in the development?
I'm not seeing a good way to keep this debt in developers' minds; it can be forgotten later.
As a general rule, technical debt increases the cost of future work on the product. So, even if you don't explicitly keep track of the debt, it will typically show as a drag on metrics such as the team's velocity over time.
Technical debt will probably also impact your team's estimates of Product Backlog Items (PBIs) during Sprint Planning, as crufty code (and debt-ridden products in general) are intuitively higher-effort.
Even though Scrum implicitly exposes technical debt through velocity, and also reflects it within PBI estimations, it's often better to track the debt explicitly on the Product Backlog. Some reasons to do this include:
If you treat technical debt simply as work to be prioritized, as opposed to some special kind of non-work work, then the Product Backlog it certainly the right place for it.
Create PBIs for the technical debt the same way you would for any other type of work. The PBIs should be written at whatever level of granularity would be appropriate for the work's level of prioritization within the backlog.
For example, you might keep some valuable but non-essential refactorings as an epic for "someday." In contrast, essential patches or rework should be written as individual user stories when the team is ready to decompose the work during Sprint Planning, or during Backlog Refinement when the work is likely to be in scope for an upcoming Sprint.
The standard Scrum answer would be to ask the team what they think. Scrum Teams are supposed to be self-organizing, which means that they can choose how to best complete their work. The team should be able to identify the management of technical debt as a problem and then come up with ideas.
However, in the real world, sometimes, the team may not be experienced or savvy enough to see these problems before they are too late. Good coaching from someone who has experienced these problems before can help with guiding the team to ask the right questions and think about certain problems before they become problems.
I would have no objections if the team would want to keep technical debt work tracked in the Product Backlog. I think that this is probably the right thing to do - it can be reviewed with the rest of the Product Backlog. If there are dependencies between technical debt and features (such as resolving the technical debt would lead to a higher quality feature being delivered in less time), these can be identified and managed by the Product Owner and Development Team.
Yes, technical debt will, at the end of the day, end up in your task tracking system in one way or another.
An obvious way:
Also, over time, it usually becomes pretty obvious to team members, even in the planning phase, where the actual debt is. Sure, there some insidious debt which increases very slowly, but some things are pretty obvious. These, also, should end up in the backlog.
Finally, you can do pro-active debt-management, for example by regularly making sure that all 3rd party components are updated regularly; that deprecated components (which have no new versions for X months/years) are phased out, and such. All of this, again, are simply more backlog entries marked "technical debt".
Should we register it as another task in the product backlog to review in another sprint? Or should we put it in some document related to this product, so the team can actually know what tasks should be treated later in the development?
I think you should actually have a well structured plan on how to tackle technical debt.
Find metrics to capture the importance of doing this tasks for the overall health of the project. Some examples are:
