Teams often struggle to fit refactoring or other technical cleanup into their sprints. First, there’s the challenge of convincing a product owner that technical debt should be paid off rather than allowed to accumulate. And even after a product owner agrees, it can be hard to fit the refactoring into a sprint given all the other distractions, interruptions, and changes many teams endure.
In this post, I outline three common approaches for making time for refactoring. For each, I’ll describe the approach and its pros and cons.
Allocate a Fixed Amount of Time Each Iteration
A first approach is to allocate a fixed amount of time to refactoring in each iteration. This could be a number of hours, a number of story points, or a percentage of either. For example, a team might decide to reserve 30 hours, 4 story points, or 10% of their time for refactoring and other technical tasks.
Because I prefer capacity-driven sprint planning I recommend reserving a number of hours. This is also the easiest: the hours used can easily be tracked during the sprint so the team can decide if sufficient time remains to take on an additional refactoring.
Pros and Cons of Allocating a Fixed Amount of Time
A big advantage of this approach is how easy it is to implement. A team can commit to this in the morning and be doing it the same day. An additional advantage is that refactoring becomes part of a team’s regular routine, freeing a team from the burden of having to discuss and schedule the technical cleanup work.
It can be hard, though, to decide how much refactoring and technical cleanup time is appropriate. Even when developers and the product owner agree, it’s a challenge to know if they’ve agreed on the right amount.
Further, a fixed amount will be hard to achieve every iteration. If twenty hours are agreed to but only fifteen are available in a given iteration, do the remaining five roll forward into the next iteration and the team plans to devote twenty-five hours then?
A final drawback is that there will be times when more or less refactoring is appropriate. A significant looming deadline may warrant reducing the amount of time reserved for refactoring. A period with less aggressive deadlines may warrant increasing the amount of time.
When Taking on Debt, Identify When It Will Be Repaid
The second approach for fitting refactoring into your sprints is to identify when you’ll pay off the technical debt at the time you choose to take it on.
I bought a really nice portable solid-state drive today. It cost $449 and I put it on my credit card. That’s debt. But I also identified when I’ll pay off that debt—I’ll do it when I get my credit card statement, which is the 23rd of every month.
A team can apply this same approach by creating a product backlog item that says “pay off technical debt of such-and-such” and then putting that in their product backlog. The item should be placed such that it rises to the top and gets included in the sprint they earmarked when they took on the debt.
For example, suppose a team has a major deadline in three months. For that deadline to remain feasible they take a shortcut today. When they make that decision, they immediately write a backlog item and insert it into the backlog such that it surfaces in, let’s say, four months.
Pros and Cons of Identifying When Debt Will Be Repaid
The biggest advantage to this approach is the flexibility it provides for determining when debt will be paid off or other technical work undertaken. Some technical debt warrants being paid off relatively quickly. Backlog items to pay off that type of debt can be placed near the top of the product backlog. Other debt can remain longer without causing problems, and items to pay those off can be placed lower.
This approach is also extremely easy to stick with over the long term. It can be started and stopped as needed.
The biggest drawback to this approach is that it doesn’t address pre-existing debt or other technical issues. To address those, a team would likely select one of the other approaches, perhaps in combination with this approach.
Maintain a Separate Technical Backlog and Work on Refactoring as Time Permits
A third common approach to fitting refactoring and other technical work into your sprints is to maintain a technical backlog and have team members work on it as they have time.
For example, late in an afternoon a programmer may prefer to work on a small refactoring rather than begin a larger new product backlog item. At 3:00 someone may not have the mental energy to initiate a product backlog item, perhaps a user story, that may involve three or four people and take three days to complete. But that same person may have the energy to do a two- or three-hour refactoring.
Many teams who work this way maintain a “technical backlog.” For some teams, this is nothing more than items that are tagged and stored with the rest of the product backlog. Other teams will maintain their technical backlog on a large piece of paper in a team room or in a shared document.
Pros and Cons of Working on Items from a Technical Backlog as Time Permits
An advantage of this approach is that it is very easy to implement. But that comes with the drawback that it can be hard to continue. A team may adopt the mindset of, “Whenever someone has an hour or two left in the day and feels like it, try to clean up some old debt.” But when schedule pressure arrives, this can be hard to stick with. A team may then go several months (or more) without any attention to accumulating technical deficiencies.
Some may be tempted to say that the existence of a technical backlog is itself a drawback. I don’t fully agree.
Items on this type of list tend to be the things that take no more than a handful of hours to do, and teams pursuing this approach have the trust of their product owners to decide when to fit that work in. Items on this type of backlog are analogous to me needing to fill my car with gasoline on one of my next few trips out. My tank is under half full. I rarely drive very far. There’s no urgency to filling my tank so it’s not on tomorrow’s to-do list (or tomorrow’s backlog, if you will). It’s just something I’ll do when I have a spare ten minutes on one of my next outings.
No Matter How You Do It, Make Time for Technical Cleanup
Teams often struggle to find time to pay off technical debt or clean up shortcuts they may have taken months or even years earlier. When these deficiencies are allowed to remain in a product, problems do compound, which is why the debt metaphor resonates so strongly.
Notwithstanding the three approaches outlined here, I prefer a fourth: avoid ever taking on technical debt.
But that isn’t always practical. And sometimes a team takes on technical debt unknowingly. And so it’s important to have a strategy for paying it down.
My Approach
When a team does need to take on technical debt, I prefer to immediately identify exactly when that debt will be paid. If I ask a team to take on debt today, I’ll pick a date in the future and commit to giving the team time to pay it off then.
I can’t say I have always honored that commitment. I may tell a team they’ll have time in three months to address the technical shortcoming. And when three months have passed, I may have to tell them it needs to wait one more month. But I can’t recall ever needing to delay the payback more than once.
