Should story be pulled out of sprint if it's discovered that it isn't sufficiently refined?
If it's discovered that a story in the current sprint is actually not sufficiently refined after the sprint has started, what's the best way to handle this? Is it OK to leave it in the sprint while team tries to refine it further, or move it to the product backlog and address it in future sprint?
The first question that comes to mind is whether the Sprint Goal can be accomplished without the story? That should help with the decision the team makes. And I do not believe there is a rule for this. Every occurence should be treated separately.
I will point out this passage from the Scrum Guide section that describes the Sprint Backlog. I added emphasis on the part I think is most relevant.
The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.
It's still in the Product Backlog, and it will remain there until it has either been retired or is Done. What you have learned is that it is not yet Ready for Sprint Planning, has been planned in anyhow, and now forms part of the forecast of work for achieving the Sprint Goal.
The immediate issue is whether or not the team can still meet their Sprint Goal commitment. If they can't, they'll need to tackle this item now or find an acceptable workaround to it.
The team will also need to resolve the matter of insufficient refinement, and no later than the Sprint Retrospective. By the time an item gets to Sprint Planning, the question should never be can this work be Done, but rather should it be Done this Sprint to meet the best Sprint Goal.
I agree with Daniel. The first place to start is the Sprint Goal. If removing the Product Backlog Item would result in the team being unable, or even less likely, to satisfy the Sprint Goal, the Product Owner should become involved. The Product Owner is accountable for maximizing the value delivered, so they would have the insight to make the best decisions on how to proceed forward and deliver the most possible value to the stakeholders within the Sprint.
However, if the Sprint Goal isn't at risk, then it's entirely up to the Developers. Leaving it on the Sprint Backlog and trying to refine and complete it is one option. Putting it back on the Product Backlog is another. If they do put it back on the Product Backlog, maybe there's another well-refined piece of work that can be brought in. Since the Developers are accountable for the Sprint Backlog, they should be the ones who make the final decision. They should also make their decisions clear to stakeholders in how they update and present the Sprint Backlog.