During product development, changes in technology and regulations require the team to reassess product architecture. How should this technical debt be captured?

Question

Options

• AInclude it in the product backlog and use a new indicator to annotate that it is technical debt
• BInclude it in the product backlog as a low-priority issue
• CSince it is not a part of agile methodologies, it should not be tracked
• DHave team members maintain personal lists of issues and consolidate the lists during review

• A
  76% (16)
• B
  5% (1)
• C
  14% (3)
• D
  5% (1)

Explanation

Technical debt must be made visible so it can be prioritized and addressed alongside feature work. The product backlog is the correct home for all work items, including technical debt. Using a dedicated indicator or tag (A) distinguishes technical debt from feature stories, enabling the product owner to make informed trade-off decisions. Adding it as a generic low-priority item (B) risks it being permanently deprioritized without the context that it stems from technical debt. Claiming technical debt is outside agile (C) is false - agile explicitly encourages transparency about technical health. Personal lists (D) create silos and lack team-wide visibility. Transparent, annotated backlog entries are the industry-standard approach.

No community discussion yet for this question.