[Summarized answers inserted] When working in a feature branch and I find code that should be refactored that is not related to the branch aside from the fact that it is in the same file I am working in.
Should I create a new user story?
- The consensus is that there should indeed be some sort of new PBI covering the refactoring. [User Story, Bug, Issue]
Also how do you write a user story for refactoring code?
- Referencing @DocBrown comment, How to work on not User Story related tasks.
- You should indeed structure refactoring as a User Story and make an effort to put it in these terms to focus on its potential value to the business.
- Citing reasons like: Technical Debt and How the responsibility of refactoring is inherited from the past feature that did not meet quality standards, therefore never should have met the Definition of Done
In the case of smaller fixes, does it justify creating a PBI and a branch to fix?
- As answered by @DanCornilescu, There are reasons for separating the fix from the current work in progress such as, creating unnecessary conflicts in your branch, or creating a distraction from what your were supposed to be doing.
- Also added by @DanCornilescu is the value added when working on teams. If fixes are addressed in a personal branch and not added to Project management, other devs may make the same fixes.
Would it be poor practice to just try and and find the closest relating user story and shoehorning a task in?
- It would seem, that giving an answer to this can only be done on a case-by-case basis. Although based on the preceding arguments, it seems it would be worth the effort, if you cannot find an appropriate place to add your new requirement then it should probably be verbalized in a new User Story.
- I also want to reference the answer by @S-Lott from What is the best way to handle similar functionlaity in separate user stories / Product back Log Items? to reminds us that User Stories are not features and how it pertains to "shoehorning".