Technical debt is a necessary evil, and its scope is expanding to include things like missing unit tests. You should have a plan in place to keep technical debt at a reasonable level. In an article for AgileConnection, Nishi Grover Garg provides a useful starting point.
Garg imagines it is not uncommon for teams to begin a new project according to a programming standard, around which they build automated tools to test adherence to the standard. But with time and as people get busy, the tools stop getting run. Then technical debt builds up, and nobody notices until it has become a serious problem. At that point, teams have to decide between messy solutions, including dedicating a sprint to refactoring or trying to work out a plan to divide up the debt and resolve it piece by piece over the next several sprints.
To avoid such situations in the first place, Garg’s solution is to have a really substantial definition of done on your projects. This is a straightforward way to put guard rails on the project, so to speak. She shares these pointers as examples of what can go into a great definition of done:
- All acceptance criteria for the user story must be met
- Unit tests must be written for the new code and maintain a 70 percent coverage
- Functional tests must be performed, and exploratory tests must be performed by a peer tester other than the story owner
- No critical or high severity issues remain open
- All test cases for each user story must be documented and uploaded in the test management portal
- Each major business scenario associated with the user story must be automated, added to the regression test suite, and maintain a 70 percent functional test coverage
For a longer discussion on the ways that technical debt pops up in the first place, you can view the original article here: https://www.agileconnection.com/article/paying-technical-debt-your-agile-projects