> I will flat out reject stories that are "refactor". Instead, just do it, and spare us the prioritization debate.
Or alternatively, don't, because the message from management is that maintenance takes a back seat to shipping new features.
For example, my team has been using a home-brewed NodeJS-to-Kafka library. Now, everyone on the team understands that this library is suboptimal in a number of ways (most notably because the developer who wrote it is no longer with the company) and that it should be replaced by some alternative from Github. But this is a change that will require quite a few downstream changes (mostly because the way the existing library was used was not well-factored).
There's no way of doing this change without it being a separate story. It's just too big a change. It's also not really something that is easy to do efficiently in an incremental fashion -- having two Kafka libraries simultaneously in the codebase is an even worse situation to be in than having a single, suboptimal library. And management is not willing to authorize a separate story for a "refactoring" such as this one, even though it would result in significant operational savings (less memory usage, fewer server restarts, etc). So we bumble along, waiting until the pain becomes so severe that we're ordered to embark on a hasty rework in order to hurriedly patch in the new library when the system finally melts down.
Or alternatively, don't, because the message from management is that maintenance takes a back seat to shipping new features.
For example, my team has been using a home-brewed NodeJS-to-Kafka library. Now, everyone on the team understands that this library is suboptimal in a number of ways (most notably because the developer who wrote it is no longer with the company) and that it should be replaced by some alternative from Github. But this is a change that will require quite a few downstream changes (mostly because the way the existing library was used was not well-factored).
There's no way of doing this change without it being a separate story. It's just too big a change. It's also not really something that is easy to do efficiently in an incremental fashion -- having two Kafka libraries simultaneously in the codebase is an even worse situation to be in than having a single, suboptimal library. And management is not willing to authorize a separate story for a "refactoring" such as this one, even though it would result in significant operational savings (less memory usage, fewer server restarts, etc). So we bumble along, waiting until the pain becomes so severe that we're ordered to embark on a hasty rework in order to hurriedly patch in the new library when the system finally melts down.