Refactoring ensures that your agile team does not encounter the same bugs later. The majority of the product owners do not allow refactoring for fear of losing productive hours. In this article at Mountain Goat Software, Mike Cohn shares four refactoring persuasion tips that your product owner cannot reject.
Steps to Convince for Refactoring
Refactoring inevitably changes the structure of the code but not its behavior. Though teams cannot fix bugs during the process, they must clean up the code to prevent future glitches. Use terminologies that product owners resonate with, i.e., making it economically viable. Here are the four tips to convince your product owner to approve of the refactoring process:
Calculate the Consequence Cost of Not Refactoring
Collect data on the hours you would spend identifying, repairing, and confirming issues if you are not refactoring. You can also make your case using logical reasoning instead of data. Remember not to go overboard with your guesses. A wrong calculation can stop your product owner from believing your predictions. If the bugs are minor, leave them for the PO to take a call. Also, prioritize creating estimates based on hours rather than story points.
Define Response Time
The next refactoring persuasion step is to calculate the time you will take to clean the code. Create the list as you do for the product backlog. Ensure that you maintain the same unit of measurement as the first step, either in hours or story points. If refactoring is already present in the backlog list, plan a short iteration meeting just for the process.
Assess the Time Savings
Find out how much time you will save because of the process. For instance, you have taken 120 hours and six iterations to address eight highly severe and four moderately severe bugs. So, every iteration was of 20 hours. Though you cannot remove all the issues, your defects will reduce in that area. You might need just 10 hours to fix issues when you revisit them next time.
Determine the Payback Time
Calculate your payback time by dividing the hours you spent to refactor by the number of hours you saved every iteration. Follow the formula given below:
Payback Period = Hours to Refactor / Hours Saved Every Iteration
Always look for the quickest payback periods. Nevertheless, do not fix the iteration numbers within which the team needs to refactor.
To view the original article in full, visit the following link: https://www.mountaingoatsoftware.com/blog/4-steps-to-persuade-a-product-owner-to-prioritize-refactoring