Where Does Technical Debt Belong?
Should these issues be grouped under user stories / child tech tasks and be accounted for within the sprint process?
No. Oh, there are some cases where some small tasks need to be added to the Sprint Backlog in order to meet the Sprint Goal, but only stories accepted from the Product Backlog by the Team because they believe they will fit into the current Sprint should generate tasks on the Sprint Backlog. Technical debt, especially technical debt from past iterations, always belongs on the Product Backlog.
Minor caveat: technical debt that is incurred within the current Sprint, and can be corrected within the same sprint without jeopardizing the Sprint Goal, can be added to the Sprint Backlog. However, unfinished stories (including stories about technical debt) go back to the Product Backlog at the end of every Sprint.
What Causes Technical Debt
Tech debt is most often incurred when shortcuts are made or stories are implied rather than made explicit. Some examples might be:
- The "definition of done" allows stories to be marked done even when there are known flaws and/or business risks, such as partially-implemented features.
- You didn't know then what you know now about the code base, architecture, or customer requirements.
- There were missing stories on the Product Backlog, such as the stories to clean up all the references to "foo" when your organization renamed all the widgets to "bar."
- The Product Owner has accepted business risk for not adding tech-debt stories to the backlog.
There are certainly other ways technical debt can creep in. The point, though, is that technical debt doesn't just impact the Team--it impacts the whole project.
Why Technical Debt Belongs on the Product Backlog
The goal of Scrum isn't to maintain a given velocity; the goal of Scrum is to make the development process transparent throughout the organization. As a direct result of this, technical debt needs to be made visible in the only artifact that counts organization-wide: the Product Backlog.
In addition to visibility, technical debt usually slows development. This happens by making new changes hard, or by reducing the velocity of new features by requiring resources to be (visibly) spent on on correcting bugs or misfeatures. Unless you're sweeping the bugs under the rug (hint: don't do that!) then your velocity probably won't change much unless your Product Owner refuses to add technical debt stories to the Product Backlog.
Remember, the Product Backlog belongs to the Product Owner. That doesn't mean that the Team can't recommend that stories be added to the Product Backlog and prioritized; it just means that the Product Owner has final say over what is on the Product Backlog, and how each story is prioritized.
Likewise, the Team is the only entity that can estimate stories and determine what will fit within each Sprint. That means that, as unaddressed technical debt piles up, a Team that is estimating accurately will factor the debt into their story estimates. This will (correctly) slow velocity, which is how the organization can see the impact of the debt on the project.
Concrete Example
Let's say you have a continuous integration server that is underpowered. This is slowing down the testing of new features and bug-fixes, causing the Team's velocity to slow down as it takes longer and longer to complete each new story. Let's also say that the effort to build out a new CI infrastructure is something that would take substantial effort.
The right thing to do would be to create a user story about upgrading the CI infrastructure. There may be additional tasks and stories associated with this, so capture them all. These stories should be passed to the Product Owner for inclusion on the Product Backlog.
Now, if the Product Owner makes this a priority, then this will be a hiccup that gets smoothed out in the next Sprint. However, the Product Owner may say: "No, this is not important enough to prioritize. I will accept the cost to the project of lower velocity in order to prioritize other features that are more important to the stakeholders."
That's okay! It doesn't mean more work for the Team, it just means reduced output from the Team in exchange for prioritizing some other business need as determined by the Product Owner. This is both legitimate and transparent, and therefore proves the value of the framework.
Include Debt in Your Estimations
When you estimate stories during Sprint Planning, outstanding technical debt will be a visible drag on story estimates. Something that may have been a 1-point story without the debt may become a 5-point story because the debt remains unpaid.
Remember, story points are a measure of relative effort. As the effort to deliver features increases, the estimates should increase as well. As a result, the Team's actual velocity will rarely change as a result of technical debt unless you are misusing velocity or allowing others outside the team to provide estimates. The only thing that will decrease is the rate of new features, and prioritizing debt stories to improve the rate of delivery is the job of the Product Owner.
Your job as the Scrum Master is to make sure the Product Owner and the Development Team are both giving sufficient information about how to use the Scrum process to communicate about these issues effectively. The Product Backlog is the right tool for addressing technical debt, but communication is the essential mechanism by which technical debt is moved from unseen roadblock to actionable item.
