[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 DoneIn 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. 
How to address tangential refactorable code in a feature branch
agile;scrum;branching;team foundation server;user story
Personally I'd just file an issue for tracking it, to be fixed in the main development branch (or wherever such items are addressed in your larger project/org), for several reasons, all ultimately translating into adding more obstacles to overcome for your very own feature:any unnecessary change in a feature branch could create unnecessary conflicts in future branch merges, including for your own feature branchit's a distraction from the agile methodology point of view, you'd waste your time doing something else than what you were supposed to do for your featureOther developers touching the same file are likely to notice the need for refactoring as well, in their own feature branches. With a policy of open season for such work it's likely some will jump on it as well, causing more trouble than good due to conflicts. Thus having a tracking issue is very important:refactoring is visible and not forgottenrefactoring will be done w/ proper planning, establishing the story it belongs to, who will do it, when, in which branch/release, etc.everyone is on the same page