11

Scrum emphasizes that all members of the team must know the technical debt of the product. But sometimes, this debt is not tangible as a simple to-do list. Should we register it as another task in the product backlog to review in another sprint? Or should we put it in some document related to this product, so the team can actually know what tasks should be treated later in the development?

I'm not seeing a good way to keep this debt in developers' minds; it can be forgotten later.

|improve this question
14

Scrum Exposes Technical Debt Through Forecasts & Estimates

As a general rule, technical debt increases the cost of future work on the product. So, even if you don't explicitly keep track of the debt, it will typically show as a drag on metrics such as the team's velocity over time.

Technical debt will probably also impact your team's estimates of Product Backlog Items (PBIs) during Sprint Planning, as crufty code (and debt-ridden products in general) are intuitively higher-effort.

Making Technical Debt Explicit

Even though Scrum implicitly exposes technical debt through velocity, and also reflects it within PBI estimations, it's often better to track the debt explicitly on the Product Backlog. Some reasons to do this include:

  1. Clarifying what work needs to be done within the project to pay down the debt.
  2. Enabling the Product Owner to make trade-offs in prioritization between technical debt and new features.
  3. Providing stakeholders transparency into the hidden costs of the product's development.
  4. Keeping the project honest by treating work as work. Technical debt is just another kind of work that remains to be done.
  5. Honoring CodeGnome's Law of Transparency: "No invisible work, ever!"

If you treat technical debt simply as work to be prioritized, as opposed to some special kind of non-work work, then the Product Backlog it certainly the right place for it.

How to Write PBIs for Technical Debt

Create PBIs for the technical debt the same way you would for any other type of work. The PBIs should be written at whatever level of granularity would be appropriate for the work's level of prioritization within the backlog.

For example, you might keep some valuable but non-essential refactorings as an epic for "someday." In contrast, essential patches or rework should be written as individual user stories when the team is ready to decompose the work during Sprint Planning, or during Backlog Refinement when the work is likely to be in scope for an upcoming Sprint.

|improve this answer
  • Just a minor nitpick: velocity isn't a part of Scrum. But the point still holds - technical debt will show up somehow. If you're using Kanban with Scrum, it will probably show itself in the form of longer cycle times on WIP. If you're tracking velocity, you'll see it there. Regardless, the result on the team is exactly what you say: carrying technical debt will make your Product Backlog Items have a higher effort since the team will either need to spend time fixing these problems or working around these problems. – Thomas Owens Jul 16 '18 at 15:12
  • 1
    @ThomasOwens You're right: the Scrum Guide makes several references to forecasts based on empiricism, and offers some examples (e.g. burn-downs), but doesn't mandate the use of velocity or any particular metric for forecasting or estimation. I appreciate you calling out the distinction, and have adjusted the wording to better reflect it. – Todd A. Jacobs♦ Jul 16 '18 at 18:40
7

The standard Scrum answer would be to ask the team what they think. Scrum Teams are supposed to be self-organizing, which means that they can choose how to best complete their work. The team should be able to identify the management of technical debt as a problem and then come up with ideas.

However, in the real world, sometimes, the team may not be experienced or savvy enough to see these problems before they are too late. Good coaching from someone who has experienced these problems before can help with guiding the team to ask the right questions and think about certain problems before they become problems.

I would have no objections if the team would want to keep technical debt work tracked in the Product Backlog. I think that this is probably the right thing to do - it can be reviewed with the rest of the Product Backlog. If there are dependencies between technical debt and features (such as resolving the technical debt would lead to a higher quality feature being delivered in less time), these can be identified and managed by the Product Owner and Development Team.

|improve this answer
2

Yes, technical debt will, at the end of the day, end up in your task tracking system in one way or another.

An obvious way:

  • Joe implements feature X, and notices that there is problem Y in component Z.
  • Joe proceeds, as planned in the sprint planning, to do what he must do, but immediately registers a new task "fix Y in Z" in the backlog. Maybe he marks it with a tag "technical debt" if you have such a mechanism in your system.
  • During the next sprint planning, Joe either recalls that issue and asks the Product Owner to include it into the comming sprint; arguing why it is good etc.
  • Alternatively/additionally, the team + Product Owner could come to the conclusion that each sprint will invest some amount of time into fixing such "debt" issues, so Joe does not need to argue as much.

Also, over time, it usually becomes pretty obvious to team members, even in the planning phase, where the actual debt is. Sure, there some insidious debt which increases very slowly, but some things are pretty obvious. These, also, should end up in the backlog.

Finally, you can do pro-active debt-management, for example by regularly making sure that all 3rd party components are updated regularly; that deprecated components (which have no new versions for X months/years) are phased out, and such. All of this, again, are simply more backlog entries marked "technical debt".

|improve this answer
1

Should we register it as another task in the product backlog to review in another sprint? Or should we put it in some document related to this product, so the team can actually know what tasks should be treated later in the development?

I think you should actually have a well structured plan on how to tackle technical debt.

  • Create a technical debt backlog plan
  • Start with the items that are more "critical". I would personally start with the ones that would make it clear for the team why it is so important to get rid of technical debt, some ideas to find this task in my last point
  • Include each sprint tasks dedicated to reduce technical debt

  • Find metrics to capture the importance of doing this tasks for the overall health of the project. Some examples are:

    • Can you finish more tasks per week?
    • Is it possible to make more accurate estimates?
    • Has there been an improvement on the time for on-boarding (and off-boarding) individuals
|improve this answer

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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