Maintaining larger projects makes it more difficult to balance refactoring and upgrade tasks according to its actual value. Consider to create and periodically maintain a summary, which helps you and your team in the decision which refactoring task should be taken next.
Here is an template on how you might categorize your tasks:
Technical debt | Estimated Efforts | Customer value | Customer value explained | Developer value | Developer value explained |
---|---|---|---|---|---|
Short title for the task | Score from 0-5 | Score from 0-5 | Explanation | Score from 0-5 | Explanation |
Note: Skip generic phrases like "reduced future" or "speeds up future development" as explanation since they are true for nearly all tasks.
Technical debt | Estimated Efforts | Customer value | Customer value explained | Developer value | Developer value explained |
---|---|---|---|---|---|
Add continuous integration in Gitlab | 4 | 0 | - | 5 | Dev machines are not blocked on test runs; Code Reviews include test badge; Automatically merge a PR on green tests |
Upgrade Rails | 5 | 0 | - | 5 | New Rails features are accessible |
Replace slider framework | 4 | 4 | New framework supports WCAG Compliance Level; Asset file size could be reduced | 2 | New slider library has a better API |
Add capybara_lockstep | 2 | 0 | - | 5 | Reduce flaky integration tests |