I am noticing a weird mentality, when it comes to refactoring code, and I am not too sure about how I am perceiving it.
Overview of the current project:
A web application used as an extension to an existing 3rd party web application. The 3rd party application maintains schedules between customers and vendors. The extension allows for modifying days/times that the customer requests to re-schedule, change the current set of schedules in case of emergency, change a vendor if they can no longer be contracted, and create the appropriate billing files. As far as development, the team is setup to follow most of the ideas of Scrum.
The system was built under many assumed one-off criteria, mainly due the customers of the project not fully understanding their internal processes (due to internal training/turnovers). We have seen many areas, where there are checks based on containing some hard-coded string.
This brings us to the issue. There is a check for a specific vendor (we can call it SomeVendor), and the check is set for if name contains Some. Later as we gain and lose vendors, another vendor gets added as SomeOtherVendor. The problem with that is of course the check based on containing Some. SomeVendor is a specific case that needs to be checked, and their are other vendors that need to similarly be checked and branches in their own set of functionality. In finding those checks, we see that it was developed in respect to a schedule can be related to a vendor but is not always assigned to them. The users would associate it during run-time.
The customer realizes that there is an issue with SomeVendor and have requested a defect be put into the backlog and have prioritized it with the product owner. I picked up the defect and developed a lookup table for the valid SomeVendor vendors (in case more than one was ever valid based on Id).
There is a mid-Sprint deployment coming up, so I went to discuss if there would be a need to add this to the deployment with my lead. He expressed that he liked the solution but asked if I could make it in a way that would incorporate mapping all vendors that need to be checked. He also stated making it solely for the current issue.
The following day the senior developer asks to work with me on the design and proceeds to discuss configuring all of the vendors and incorporating that into the codebase. As stated above, the system accounts for some of the vendors as they "can be" of some Type, but it is not always the case.
We discussed the point that the system only accounts for it as a can be, but it is not determined until they save at run-time. The suggestion is to bring this to the product owner and get the criteria from the project customers.
I see the point in refactoring to a point where the codebase would use this correctly, but I feel like it is stepping into the realm of over-engineering at this point. That feeling is mainly due to a story/defect has already be determined and prioritized with the customer, and we have given what we said we would do from the Sprint planning. This feels like we are sneaking in a deliverable that they don't know that they need (which has been discussed recently between us and the customer).
Is this type of refactoring something that should be happening, or is this a sign of bad technical pushback? In reality, it does not matter to me if the answer specifically deals with agile. It seems odd to me in the sense of the team having some requested work then delivering something that wasn't agreed.