Debt Cycles
Our software team observes regular "Debt Cycles" dedicated to addressing tech debt that has accumulated over time.
Frequency
Every fourth cycle is a debt cycle.
General Guidelines
Both the Automations Team and the Portal Team will follow the same Debt Cycle schedule.
Each team will plan its own tech debt cycle, incorporating a mix of older and newer debt tasks.
Priority may be explicitly discussed during cycle planning or determined by individuals handling the tasks.
Priority typically goes to tasks with high impact or those that have been outstanding the longest.
The Director of Technology may participate in the tech debt cycle or focus on innovation during this time.
Debt Cycles will not be skipped or rescheduled.
What We Tackle During Debt Cycles
Critical/blocking issues that arise (as handled during a normal week)
Tasks included in the tech debt cycle
Cleaning up personal workspaces, email inboxes, etc.
Work-related education and cross-functional collaboration
(managers) A full review of the issue backlog for your team
What We Avoid During Debt Cycles
During our debt cycles, we avoid any feature development work until all the following conditions are met:
All debt tasks are resolved, or remaining debt tasks are too big to practically start working on before the debt cycle ends
No critical/blocking issues are outstanding
The backlog has been fully reviewed and prioritized
Personal workspaces are cleaned and organized
Handling Backlogs
To avoid "clobbering" our debt cycles, products may not be released with known critical/blocking tech debt, even if a Debt Cycle is scheduled immediately after release.
Because debt issues may be addressed up to six weeks after creation, debt issues must be documented with a thorough explanation.
If resolving a debt issue takes less time than creating a detailed ticket (e.g., less than 15 minutes), fix it immediately, creating a ticket only if necessary for changelogs. Otherwise, create a detailed ticket and assign it the "debt" label.
Focus Time During Debt Cycles
Team collaboration is encouraged.
Focus time is permitted but less rigidly enforced than during a normal sprint.
"Do Not Disturb" is discouraged unless absolutely necessary to resolve a particularly complex issue.