0

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.

Tushar
  • 672
  • 7
  • 10
Liero
  • 19,054
  • 16
  • 100
  • 195
  • 1
    I'm voting to close this question as off-topic because project-management should be asked at [Project Management](https://pm.stackexchange.com/) – BDL Aug 14 '17 at 09:34
  • 3
    I'm voting to close this question as off-topic because it is not about programming. – Vadim Kotov Oct 25 '17 at 09:01
  • @VadimKotov: Then, what are the `agile` and `scrum` tags good for? – Liero Oct 25 '17 at 09:48
  • 2
    @Liero they are obsolete here and eventually will be deleted. Take a look at the description of it. Now we have [Project Management SE](https://pm.stackexchange.com/) and [Software Engineering SE](https://softwareengineering.stackexchange.com/) for such questions. – Vadim Kotov Oct 25 '17 at 09:50
  • I'm voting to close this question as off-topic because [project management is off-topic on Stack Overflow](//meta.stackoverflow.com/questions/343829/is-stack-overflow-an-appropriate-website-to-ask-about-project-management-issues/343841#343841). Ask these questions on [SoftwareEngineering.SE](//softwareengineering.stackexchange.com/) and [ProjectManagement.SE](//pm.stackexchange.com/) instead. (You can also flag for moderator intervention to have this question migrated.) – robinCTS Oct 28 '17 at 01:35

2 Answers2

4

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.

Barnaby Golden
  • 3,781
  • 1
  • 19
  • 24
  • I agree with @Barnaby_Golden, though I think he's buried the lead somewhat. You always have to consider the value of the items you're planning to do, but make sure you're talking about the right value. If you're working for a business, the business value of your work should take precedence over the value of the work to the Scrum team. It can be galling to a developer to let something alone when there's some technical debt, but if there's no business value in fixing an issue immediately, it can sometimes be better to defer the work until a later sprint when it can be properly prioritized. – Michael Peacock Apr 13 '16 at 14:27
0

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.

Tushar
  • 672
  • 7
  • 10