(From my chat history with Michael Robinson.)

(11:16:46 PM) xcqmichael: In your situation, it’s important to understand that there are two ways oflooking at software, the coder way and the business way.
(11:17:22 PM) xcqmichael: The codersayssoftware is successful if all the tests pass, the code is well structured, and easy to understandandmaintain.
(11:18:01 PM) xcqmichael: The businessman says software is successful if it deliversmorevalue to the business than the business spent to create it.

(11:19:22 PM) xcqmichael: You separate them in terms of pain points.

(11:25:00 PM) xcqmichael: point 1:
(11:25:53 PM) xcqmichael: Refactoring stories (or othertechnicaldebt stories) are like any other kind of story; they should follow INVEST criteria, they should haveanestimated effort, and they should have a prioritized business value.
(11:26:18 PM) xcqmichael:Because, in the end, it all comes down to cost to code vs. value to business.
(11:26:28 PM)xcqmichael: point 2:
(11:27:12 PM) xcqmichael: Refactoring, by definition, means making changestothe structure or organization of a code base without changing its functional behavior.
(11:28:06PM)xcqmichael: When you have a code base that is fragile and has no test coverage, it is very costly torefactor because it is very costly to confirm you have not changed functional behavior.
(11:28:12PM) xcqmichael: point 3:
(11:28:51 PM) xcqmichael: When the cost of a technical debt story isveryhigh, then the business value must be even higher.
(11:29:44 PM) xcqmichael: Consequently, theworsethe code looks to you from a coder point of view, the more you should leave it alone from a businesspoint of view.
(11:29:51 PM) xcqmichael: point 4:
(11:30:27 PM) xcqmichael: Therefore, whensomeone says, “there’s whole bunch of code needs to be refactored”, probably, none of it should be.

(11:31:49 PM) xcqmichael: Well, it all comes down to prioritization.
(11:32:00 PM) xcqmichael:And aclear sense of the cost/value tradeoffs.