Introducing a user story, mid-sprint without adequate estimate.

The Scrum Guide clarifies that the Sprint Goal is the commitment. The work on the Sprint Backlog can be seen as a forecast of whatever is needed to meet the Sprint Goal.

Developers would commit to a goal rather than to a forecast of work. They do not necessarily commit to completing any items in a Sprint Backlog at all.

Focus is one of the Scrum values along with commitment. I'm more interested in why the team agreed to bring in new work mid-Sprint if they already had work in progress which a developer ought to help finish.

Ian is absolutely right that the team doesn't commit to the Sprint Backlog, but to the Sprint Goal. Not every Product Backlog Item selected for the Sprint Backlog needs to relate directly to the Sprint Goal. In cases like this, the team may fill the Sprint Backlog with other Product Backlog Items based on their capacity and use the Sprint Goal as a focusing tool. This can help the team make decisions if unexpected things come up in the Sprint that reduce capacity or increase the work needed to achieve the Sprint Goal.

The Scrum framework doesn't have that many rules around estimation. An estimate isn't a required attribute of a Product Backlog Item. The only rule that is relevant is that each Product Backlog Item is scoped such that it can be completed within a Sprint. I interpret this as meaning the team - based on their way of working, whether it is individual work or pairing or mobbing or review-gated - believes that they can take that Product Backlog Item from not started to done before the end of the Sprint timebox if it is started on the first day of the Sprint. However, in my experience, most teams like to have much smaller Product Backlog Items, where the work is typically something that can be completed in a couple of days.

These rules and guidelines aren't about completing work in the Sprint that they were started in, although it's best to complete work within a Sprint or risk waste. Work that is not complete before the end of the Sprint could be reordered as a result of the Sprint Review, meaning that it is no longer important or valuable. This work-in-progress may become waste if it needs to be set aside or reworked because of feedback.

I'd also suggest that pulling in a new Product Backlog Item isn't necessarily the best thing that a team member could do if they find themselves having additional capacity during the Sprint. There are plenty of options that I'd consider better. Some of these options include helping with other work, pairing to learn something new about the product or technology to build the product, refinement of Product Backlog Items in the Product Backlog, self-study and improvement to become more cross-functional, paying down technical debt, doing overhead work, or even taking a break to maintain long-term pace. The choice of what to do is highly dependent on the context, but pulling in a new Product Backlog Item, especially one that cannot be completed within the Sprint timebox, is the last thing that I'd do.

Thanks @Ian and @Thomas for your excellent suggestions (and correction on terminology) and providing a good soundboard.

To add some context.  The scrum team is new and just over halfway through Sprint 2 (2 week sprint).  In fact, all team members are ~1day each from achieving the Sprint Goal and will soon be calling the Product Owner for more work to be allocated from the Product Backlog (Jira).  The Product Backlog for the next Sprint is refined, but some user story estimates are outstanding.  

As you have both mentioned, I will look at options to keep the team busy supporting other team members, refactoring etc, while awaiting Sprint 3 and take lessons on improving estimations.  Thank you.

I don't understand how "all team members are ~1day each from achieving the Sprint Goal". The team, not individuals, achieve the Sprint Goal. In the past, when I've seen this kind of way of looking at progress, it's been because the team is made up of individuals with specialized skills. If you have people with unique or highly specialized skills, I'd suggest that a way to keep the team productive would be to cross-train people. Especially focus on single-points-of-failure - if there is some knowledge or skill that only one person has, that is something that should be learned by more of the team.

You are correct, my organisation has recently adopted the Scrum framework and the Scrum team is made up of individuals with specialist skills (which can be learned).  There are lots of things we need to work on together to improve, one of them is cross-functional training, as this is the teams biggest single-point-of-failure.  It will be a busy year.

Ideal way - Be ready with shovel ready sprint backlog for 3 future sprints .

If this is not possible , try to refine stories regularly for at least 1 sprint ahead, this way team will be saved in this kind of sudden capacity increase.

Mid sprint without refinement , adding story is a big no, as ever changing dev requirements/ environments can commit for 2 week commited time/sprint goal.

For ever changing environment / requirement like support -> go for Kanban