I have recently gone live with a big project. To meet a tight deadline some technical debt was accumulated but the true extent only became apparent after go live.

As this is intended to be a scalable application, these problems which could be deep seeded into the code have to be resolved.

Should these issues be grouped under user stories / child tech tasks and be accounted for within the sprint process? I think not as it is fixing existing functionality and should be logged as tasks / child tasks outside the sprint process. Or should I add them to account for what the team is doing?

Many thanks.


3 Answers 3


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:

  1. 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.
  2. You didn't know then what you know now about the code base, architecture, or customer requirements.
  3. 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."
  4. 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.

  • 5
    nice answer, plus I still admire you for writing such a long and detailed answers. It must take a lot of time.
    – Zsolt
    Nov 28, 2012 at 6:59

Every task that the team is going to perform should be documented and accounted for in each sprint. Whether it is a user story, bug, or technical debt, every item should be assigned appropriate points so that the team continues to monitor its proper velocity. Another advantage of this is that all the stakeholders know that is being done and why.

For the issues you have encountered, new stories / technical debt tasks should be created and added to the sprint backlog (as per the team's velocity). These may cause some user stories (maybe feature requests) to be pushed into future sprints, which is fine as long as the stakeholders agree that paying off technical debt provides more value as opposed to feature requests.


Should these issues be grouped under user stories / child tech tasks and be accounted for within the sprint process?

it depends (how big and how critical these bugs are)

if the item is big enough (critical bug and fixing will require to modify lots of code) then it looks like a story (or even epic)

on the other hand - you might have bunch of smaller independent items - just put them all into "active bugs" box and work on those when you have time

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.