During product development, changes in technology and regulations require the team to reassess product architecture. How should this technical debt be captured?
A.
Include it in the product backlog and use a new indicator to annotate that is technical debt
B.
Include it in the product backlog as a low-priority issue
C.
Since it is not a part of agile methodologies, it should not be tracked
D.
Have team members maintain personal lists of issues and consolidate the lists during review
A. Include it in the product backlog and use a new indicator to annotate that it is technical debt
This approach ensures that the technical debt is visible to the entire team and stakeholders, and it can be prioritized and managed just like any other backlog item. Using a new indicator specifically for technical debt helps differentiate it from other types of work, making it easier to track and address appropriately.
I chose B first and then changed back to A. But not really too sure why it needs to be annotated as a Technical debt.
The key word is Lower priority item - which may not be true. This really depends on whether quality or speed is the main focus and different debts will have different prioritisation levels since they are also risks
A = seems to be correct, but I don't see the need of accenting that it is technical debt since it is not. Regulations cannot be tech debt.
B = cannot evaluate the priority by yourself conviction
C = It is part of the Agile
D = There's no transparency
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
thewalker
3 weeks, 2 days agofletcher_ng
1 year, 3 months agoPetrevski
1 year, 4 months agoMinhha3
1 year, 5 months ago