How to fit refactoring into your sprints?

Do you enjoy building meaningful well-rounded products that engage users and are able to deliver the desired outcome in a matter of milliseconds?

If yes, you are just like us!

Building such products though is not always possible right from the start, nor is it always needed. Depending on the product vision and the various constraints, development teams often focus on delivering functionalities at the start of the project, accepting that there will be some technical debt acquired along the way. There will come a point when you have to pay some of this debt back if you want to keep an efficient functionality delivery rate.

Even though it is everyone’s job to preserve quality, usually, it is the engineers that spot the weak links first. They are often the first ones to proactively suggest technical improvements/upgrades/refactoring even before users report any feedback. However, due to the technical nature of their request, its importance can easily be underestimated as it is hard for non-technical people to see how it adds value directly.

Let’s imagine you came up with an idea to refactor how a certain functionality works. Maybe you even added a story to the backlog. Then what?

This article will give you a six-question framework to help you prepare for negotiations with stakeholders. We will also offer you some tips and strategies to help you get your idea understood and prioritized and help your story make it to the sprint.

There are 6 questions you can cover to pitch any new idea in general. They are equally helpful when you want to convince the team to take a refactoring story into the sprint.

Whatever your idea is, you should know the full scope of it, including but not limited to:

1. What should be done to deliver it?
2. What other parts of the application does it affect?
3. How long would it take approximately?
4. What are the risks it holds?
5. When would be the best time to work on it bearing in mind the current roadmap and the dependencies?

The answers to these questions have the potential to pile up as quite a large mass of information and you might not end up presenting or even using all of it (in fact you might use only 15-20% of it) but they will prepare you with a solid base going forward with the next steps

a. Yes, usually that would be your PO. Often though, especially if your idea is big enough to require a change of direction, the PO’s opinion might depend on other key stakeholders – like the budget holder or the key stakeholders whose work you will affect the most. The refactoring investment could change someone’s workflow, affect the budget, or delay the implementation of new features.

b. In situations where your PO would not be the sole decision maker, your help and, especially, support to understand, prepare and, why not, even present the idea would be very much appreciated.

Constraints are always linked to one of these three parameters:

• Budget
• Schedule
• Scope

Depending on how much you know about each one, try to think why your way out of any “Against” arguments that are likely to come up. Have in mind that with refactoring stories, you would very often affect one or more of these negatively in the short term. However, the quality interacts with the budget, scope and schedule and this investment will pay off in the long run.

Be ready to address the arguments “against” but you also think about other motivational factors that would affect the decision.

Those would relate to the Product Vision and the KPIs that you use to measure the value you deliver. You should think about how implementing your story has the potential to affect any of those. This can be another card up your sleeve and it will be up to you to decide how and when to use it.

At this point, you should have gathered and considered everything that can help you. What would be the best way to present it though?

Depending on who your decision maker is and how your organization and team measure success, you should pick the communication approach that would be easiest to digest. Choose wisely and remember you have many options: you can do it verbally only, go through a story description, do a PowerPoint presentation or even present an Excel sheet focused on the return of investment.

Does it sound silly? Even though it might, preparation and practice inevitably affect your level of confidence during the actual sale. Sounding confident depends not only on how strongly you think your story must be implemented, but also on how well and quickly you can find the right wording to describe that.

Some go as far as to prepare scripts which include all the IFs and practice until they know each line by heart. Do whatever helps you in conveying your level of certainty. However, be ready to be flexible as the conversation may take a different course than expected.

Looking for more inspiration? Here are some tips from our teammates – techniques we have used to communicate the value of technical improvements:

Return on Investment
A technique often preferred is to compare the effort the team needs to invest now with what the gains are in the future. From maintenance cost savings, to reduced time for regression testing, any expected measurable merits can be mentioned.

Start with why
Who said that refactoring stories can’t have a purpose? Sometimes the ‘user’ that benefits is the team itself. Why this story matters can be communicated for technical improvements stories, just as we communicate it for the functional improvements. Mention who gains what from the story.

Be ready with the approximate story size in advance
It’s a clever idea to size and estimate the technical stories as early as possible. This way you can provide more clarity in what is expected. In general, most people would avoid the feeling of uncertainty whenever they can. The less open questions around the story, the higher its chances of being considered.

Communicate the vision of success
Remember that the goal is to succeed as a team. Show the stakeholder you communicate the story to that you care about this success, and you are driven by it. Communicate how the story will get you closer to it.

Do not assume
People would not see the value of anything as you do until you explain it. They would not be familiar with the change you want to make. Explain the details and the context.

Size properly
Instead of stretching to ask for a sprint or a month of refactoring, break it down into smaller increments. Schedule it along with the functional work. It is easier to negotiate investment of ~10% of the sprint while you also keep your stakeholders happy with new functionality delivered, instead of putting all your efforts into code maintenance and hinder delivery.

Be open and honest
Share the whole cost of the story. If you need to invest time researching or ramping up, communicate it. Manage expectations right – tell your stakeholders what they can expect as a result and what is not certain.

We hope we helped you with some ideas or inspired you to think about the value that every activity brings.

by Stefan Ralchovski & Denitsa Stoycheva