I am new to software engineering and looking for someone with agile experience to help me understand what the recommended practice is and why. If this question can be related to a better site please note that site please.
closed as too broad by Todd A. Jacobs♦, Marv Mills, Mark Phillips♦ Oct 24 '14 at 3:15
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
Technical debt is not really "added" to projects (or rather products), it just accumulates like dust or mould if not taken care of. Technical debt is basically undone work, like not cleaning up the dishes after cooking. You can get away with it for a while, but the longer you keep it, the more it costs to actually get rid of it, and the more it slows you down.
So the recommended ideal approach is not to let technical debt accumulate, rather do the cleanup right away whenever it is required. In software, cleanup is called refactoring. If you are living in a less than ideal world like most of us here do, technical debt is prone to accumulate though every now and then. So one should focus on dealing with it regularly, in small but frequent steps, rather than trying to resolve it in a large chunk at once.
On some projects, you inherit several thousands of bug reports. It can be daunting if you attempt to encompass all of them.
- The best way is to go forward: You can develop new features, but make sure you don't repeat the same mistakes - Do include enough time for clean-ups and refactors.
- Practice the "Zero Bug Policy": At the end of each release, either you still have bugs and you postpone the release, either you close all bugs as "Won't fix". Please read the linked article, it says a lot about 1,000-bugs long backlogs.
- If you're given a project with enough slack time to look at the technical debt, it's not a good sign. The added value of your work may be difficult to demonstrate.
- You should prioritize user stories according to their value and estimates. If a user story includes a technical debt item, you'll have time to refactor. If a technical debt item isn't linked to a user story, it doesn't have any value to improve it.
I've regularly worked on projects with more than 3,000 open bugs and we just ignored them and closed old ones regularly. Those who care about those bugs may reopen them in time, but most probably most of them are long forgotten.
The answer is that there's no magic formula.
I've found however this document of the Construx guys (the same guys of the classical mistakes paper) in the Software Engineering Institute repo very rich to make my own definitions. BTW this is a lite version of their Technical Debt Management approach.
I hope it's as useful for you as it was for me.