How should we balance chores to reduce technical debt with impending deadlines for features?

Question

I'm the Scrum Master on a project with three developers, one QA person, one designer, and me. We work on a project that we inherited about three years ago, a "portal" website and a cordova app. We're now planning to scale down the team to a skeleton crew of one developer, aiming to finish up everything critical in the next ~five weeks before we do so.

The project has always struggled with the issue of technical debt we inherited along with the codebase, and now the team would like to see if there is some way we can integrate this work without it getting us "off track" on the main features and bugs we want to complete before our five weeks are up.

It's important that the team stay as focused on the features and bugs as possible because they've been working on a few pages of the app now for months and are are excited to be done with it. For their morale I want to make sure we keep that focus, but they also feel strongly that some of these engineering chores should be done.

How should we balance these two things so that the developers still feel they can make progress on the engineering initiatives while remaining focused on finishing the feature set?

Answer 1

Why are you going to a skeleton crew? Sounds like the long-term plan for these apps/sites is that they die a slow death. In that case, who cares about paying off technical debt?

Technical debt raises the cost of future work. This isn't a problem if there won't be any significant future work.

As a side note, you've had this project for three years: you should have been paying down technical debt over the past three years. Paying it down early would've made the rest of the time on your project more productive.

Answer 2

What can help is to think of everything in terms of the value it delivers.

The value of finishing the feature set is obvious, but the value of technical debt chores requires a bit of thought.

For example, say clearing out a bit of technical debt makes it easier to add new features. This then gives a small efficiency payoff with each new feature that is added. You can make a case that this kind of technical debt work has more value than just adding a single new feature.

Now start to prioritise your technical debt alongside the new development work. You may well find that certain types of technical debt end up quite high on your priorities. Other types may deliver less real-world value and so end up being lower priority.

Answer 3

they've been working on a few pages of the app now for months are are (sic) excited to be done with it [...] but they also feel strongly that some of these engineering initiatives should be done.

If that's the main reason why you'd avoid clearing away technical debt, then the first step is to talk to the Team and find out which they think is more important.

More likely, however, you probably cannot choose to simply delay the 5-week deadline in order to start cleaning up technical debt. That doesn't (necessarily) mean that you can just ignore it, however.

The fact that, once you've "finish[ed] up everything critical", the Team is being reduced to a single developer, in spite of the large bulk of technical debt, is concerning. Is that developer going to be focused solely on cleaning up the debt? Or is s/he going to be focusing on maintenance, lower-priority requirements, and other projects as well? If the latter, then the debt is just going to pile up, and the project code may end up collapsing under the weight of its own imperfections.

Whether you deal with the debt now (potentially delaying the deadline) or deal with it afterwards, either way you'll need to have sufficient time and effort budgeted to taking care of it. If you don't, you'll be paying for it down the line.

Keep in mind, however, that this applies only under the assumption that your project is going to be maintained indefinitely. If it's not, then technical debt becomes less important - especially as you get closer to the 'drop date'.

Answer 4

• Gather the team's input to build a prioritized backlog of technical debt (not all tech debt is created equal). Make sure to capture their suggestions. Its unlikely all of the tech debt may ever be addressed, but this information can feed into future "engineering initiatives" and project checklists.
• While five weeks does not leave much time to address items that are not on the "critical path", ask yourself and the team - does any of the tech debt block work on the critical path? If so, can you negotiate an extension?

Answer 5

You could also incorporate tech debt work into definition of done. I.e. 10 or 20% of time spent on delivering new feature should be spent on tech debt tasks like refactoring the legacy code.

This will work for small items and could change teams's approach to tech debt. Then you could introduce bigger debt items to product backlog and prioritise along with features.

Answer 6

Problem

You are trying to balance technical debt with product features within the Development Team, but this is a violation of basic Scrum principles. The team should be making technical debt visible and recommending solutions, but the responsibility for managing the debt belongs to the Product Owner.

Analysis

I'm the Scrum Master on a project with three developers, one QA person, one designer, and me.

You are missing a clearly-defined Product Owner. Scrum requires active participation by all three roles (Product Owner, Scrum Master, and Development Team) in order for the framework to operate effectively.

How should we balance these two things so that the developers still feel they can make progress on the engineering initiatives while remaining focused on finishing the feature set?

All work contains overhead, including refactoring and "paying interest" on existing technical debt. That should be covered in your estimates when you accept work into each sprint.

However, scheduling work that consumes substantial team capacity is never something the Development Team should be doing directly. The role of the Product Owner is solely responsible for the content and prioritization of Product Backlog Items, and it is their decision whether or not to allocate team resources to paying down technical debt or towards new features.

Of course, if there is substantial debt and it is not repaid, that acts as a drag on the team's productivity. Balancing that drag against the delivery schedule is the Product Owner's job, though, not the Development Team's.

The Scrum Team as a whole should be making the cost of the technical debt visible through estimates, velocity tracking, and retrospectives. Recommending Product Backlog Items that reduce technical debt should be done during Backlog Refinement or the Sprint Retrospective, but actual management of the Product Backlog remains the purview of the Product Owner at all times.