Should task, like "refactoring needed" be stored in product backlog?

Question

In Scrum project, developers sometimes finish their work on product backlog item but they create also some kind of technical debt. Technical debt can be created because of some impediment at that time, or lack of time, sometimes also because of lack of knowledge.

Now, when team member discovers technical debt, which should be fixed, what is the recommended way to track it? The work don't have necessarily be related to any particular feature. Should the team member just create new Product Backlog Item?

Let's say there is enough trust bewteen the develoment team and product owner, so the is no reason to hide the technical debt from him.

Answer 1

A common practice in Scrum teams is to tackle technical debt work as soon as it is discovered and to wrap the work in to the story in which the technical debt was identified.

There are two reasons for doing this:

• It is usually easier to work on the technical debt as close as possible to when it was discovered. The team members are typically in the code and so can efficiently complete the work.
• Delaying technical debt risks giving a false impression of progress. For example, the team shows 5 stories done in a sprint, but in reality there is technical debt accumulated that still needs to be resolved.

Technical debt that is not associated with a specific story can be added to the backlog.

The technical debt work will be evaluated alongside all the other backlog items. For this reason it is important to identify the value of the technical debt work. For example:

If this technical debt is not completed it will be more difficult to work on the code base and so the team's productivity will be reduced.

You may also wish to consider wrapping technical debt on the backlog in to other backlog stories. For example, a team realises that the site home page is using a deprecated version of a library. They add this technical debt to a functional story that touches on the home page, so that the debt work will be fixed at the same time as the functional work.

Answer 2

Sometimes developers know that technical debt exists in their recent code; however, there are (many) times they don't realize it at that moment. Later, they themselves or another set of developers identify the problem and by that time the debt becomes quite big (not really trivial to fix).

Although, I too believe that the debt instances must be refactored as early as possible, many times due to the size and complexity it is not possible in a given time. In such situations, the debt instances must be tracked. The modus operandi depends on the process and practices followed in the project/organization.