Finished all stories but have a lot of sprint days left

We had a planning meeting and decided which user stories to work on. 

The purpose of a Sprint is to meet a Sprint Goal. Did you remember to decide what that goal would be? Any items chosen from the Product Backlog are a forecast of the work needed to meet that commitment.

1. if you add a user story, we'll be able to finish it, but we won't have time to refactor it. Adding a user story like this will continue to prevent refactoring. 

Why? Isn't refactoring a quality concern which ought to be part of the Definition of Done?

2. isn't it against the rules to add unplanned user stories in the middle of a sprint?

Does the Scrum Guide forbid it?

It would be sensible to commit to a goal, and not to the forecast of work. Why would any backlog be frozen, instead of being open to change?

Thanks @Ian Mitchell for the reply

The story that I, the PO, suggested adding is the same direction as the sprint goal. 

To summarize your answer, would I understand that it's okay to add a new user story in the middle of a sprint if it can be completed without violating the sprint goal? 

Our DoD is to get our app to a state where we can release it at any time. 

And the refactoring that we do is supposed to be done with code conventions for legacy code, etc. 

So I'm a little confused when you say that the refactorings you're talking about should be inside the DoD. 

Thanks

I don't follow when you say that the Product Backlog Item that you'd like to add "is the same direction as the Sprint Goal". Most of the teams that I work with craft a Sprint Goal, select all the Product Backlog Items needed to achieve that goal, check the selected items against the team's capacity, and then reduce the goal if the team's capacity is insufficient to complete the selected work. Ideally, there's some buffer between the work needed to achieve the goal and the team's capacity to account for undiscovered work appearing or unexpected reductions in capacity.

Looking at the whole situation, it's a bit surprising when the team finishes all selected Product Backlog Items in the first half of the Sprint. That may indicate something happening with refinement or Sprint Planning. Even if the Sprint Goal - the most valuable step to take for stakeholders - can be achieved early in the Sprint, I'd still expect the team to be able to somehow look back on past performance, forecast future capacity, and select enough work to fill the Sprint. You do need to be aware of the possibility of unplanned work or unexpected capacity reductions, but having no remaining work in the Sprint Backlog so early in the Sprint would be very surprising.

It's also not clear what the team means by "refactoring". Refactoring is "restructuring an existing body of code without changing external behavior". It's not clear why you would need to spend time refactoring new code. Often, you would want to refactor existing code before adding new code to make the seams between the existing code and new code better. There may be some work to refactor at the end of implementing a new feature, but I wouldn't expect it to be a significant amount of time or effort if quality, including design and code quality, is built in from the beginning. If any refactoring is necessary - either to enhance old code or to clean up after implementing the new functionality - I would expect this to be included in the team's Definition of Done for the Product Backlog Item.

Generally, though, if the team has completed their work and has a week left in the Sprint, I'd expect that they'd be able to take on and complete another Product Backlog Item. That doesn't mean that they have to. There could be other things to do that would be beneficial, such as dealing with business activities that aren't product development work or cross-training.

When I think of "refactoring" the words technical debt come to mind.  It usually is not mentioned in relation to new code that is written.  It is usually done to existing code in order to introduce new code.  Or it is associated to improving existing code to complying with new organizational standards, upgrades to the technology stack, improve the performance, or to improve the ability to support the code going forward. 

I would have candid conversations with the Developers on what they mean by "refactoring".  I would also want to make sure that the Definition of Done accounts for it so that a item cannot be "done" until any refactoring activity is completed. It would also be interesting to know why refactoring was not included in their estimation of the work.  If it was, how can they say they are "done" with the story if the refactoring work has not been completed.

I also would not be advocating to add new items to the Sprint Backlog until the refactoring topic is better understood across the entire Scrum Team. At this point, that seems a better use of the team's time than bringing in more work.  It can have long term implications if everyone is not understanding it the same.  The Product Owner is accountable for ensuring the Scrum Team is working on the right things for the Product.  Sometimes that is not new functionality and I would consider this to a prime example of that.