Buffer for technical debt

Hi Rhea,

There is no guideline on this, as this is very much dependent on the entire situation. 

Is there anything hampering you to see how the feeling of the Dev Team pans out?

Are you referring to existing technical debt in the product or working to prevent technical debt from accumulating in the first place?

For the latter, prevention of technical debt, this should be accounted for however the team estimates the Product Backlog Items and plans their Sprint. There should be a consideration for all of the work that needs to happen to prevent technical debt as well as clean up some (but perhaps not all) immediate technical debt in the parts of the product being actively worked on.

For the former, removing existing technical debt, it depends. I've seen several different ways. One good example was a team that works in a large system with several defined modules or components. If they are beginning an effort in a component that they are unfamiliar with, they ask for an entire Sprint to evaluate and pay down technical debt. If there are any known bugs, they may select a small number for the Sprint and make resolving the known issues the externally visible Sprint Goal, but would also check on the amount and quality of unit tests, consistency with the current code style, look for static analysis findings that can be resolved and clean these up. Then, when they start delivering the most value in the following Sprint, they are more prepared and have a good, shared understanding of the parts of the system they will be working in. Other teams, though, allocate a percentage of their capacity to fixing bugs. Another team takes on at least one known issue per Sprint. However, it is important that the existence of technical debt is understood as it will impact the development or new functionality or the ability to make changes to existing functionality.

Technical debt by definition has a value associated to it.  New features/functionality is usually assigned an assumed value as well.  So why do yo have to specify a certain amount of time to deal with technical debt.  The work to address technical debt should exist in your Product Backlog along side all of the new work.  According to the Scrum Guide:

The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

So all work is represented in the Product Backlog and the Product Owner is responsible for ordering the the items. Again per the Scrum Guide:

The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. 

Technical debt is better understood by the Development Team so it is imperative that they make itthe value clear to the Product Owner.  There is a negative value associated to not addressing it and a positive value associated to addressing.  Both values should be clear to the Product Owner.  Then the items will be ordered and the Development Team plans a Sprint around delivering the most value.  There could be a Sprint solely focused on technical debt if they are the highest ordered items in the Product Backlog. 

It is all work that needs to be done to the product and the goal of the team is to maximize the value.  Treat it all the same. 

Need your inputs, as to how much percentage of a sprint velocity, one should reserve for technical debt?

What was the plan for repayment when the debt was taken out?