Sounds like you are saying that refactoring is usually incompetently done to me.
Not at all intended on my part. Nor would I say it is usually what went wrong.
The primary root cause is an underestimation of the true complexity of the problem. The details of which only start to become apparent after you've begun the rewrite.
An inevitable secondary cause is organizational pressures to add features to the rewrite. This happens after frustration builds because other departments have been unable to get features into the legacy code. I can't fault developers for lack of skill in managing these organizational pressures. That skill is not a core competency for developers, but it generally is for the people who are trying to get their agendas into the development roadmap.
If there is any additional challenge from the lack of skill of the developers, then you had much bigger problems from the start.
Do you mean rewrite? You're acting as though refactoring is a process that involves destroying bad code and rewriting it from scratch. It's not.
Refactoring is usually the modification of existing code while maintaining existing functionality in order to make the code easier to maintain and reason about for future developers.
Furthermore, if you're given points for refactoring (as you should be) your velocity is very unlikely to go down in my opinion. I will say that many teams and managers do not do this, but that's because they're poor managers.
If you have tests in place you will cause fewer bugs by refactoring. If you don't you will still create a few bugs as you refactor. But imo, fixing the bugs created by refactoring is just... part of refactoring. If that means the task requires an even higher number of points, so be it.
As a manager, there's no point in forcing the team to accept a reality they know isn't possible. It's not beneficial for anyone.
I mean that when developers are given leeway to devote a sprint or two to a large refactor "to take care of technical debt", it naturally turns into much more of a rewrite than expected.
I'm not a professional, but you seemed to be using refactor and rewrite interchangeably. I had the impression they were different and you seem to be applying all the bad ideas of rewrites to refactors.
Not at all intended on my part. Nor would I say it is usually what went wrong.
The primary root cause is an underestimation of the true complexity of the problem. The details of which only start to become apparent after you've begun the rewrite.
An inevitable secondary cause is organizational pressures to add features to the rewrite. This happens after frustration builds because other departments have been unable to get features into the legacy code. I can't fault developers for lack of skill in managing these organizational pressures. That skill is not a core competency for developers, but it generally is for the people who are trying to get their agendas into the development roadmap.
If there is any additional challenge from the lack of skill of the developers, then you had much bigger problems from the start.