We are using Jira at AOL right now, so hopefully I can provide some Good Practice and practical advice.
First off, let's separate this into two answers: New User Stories, Defects/Bugs
Defects/Bugs added in a Sprint: Don't Estimate- Reduce Capacity
So at AOL we face this issue a lot. We run a digital advertising system so it has a lot of customer escalation. We don't operate a maintenance team, so bugs end up with the feature development teams. Recognizing that interrupting a sprint is bad, we took a hard look at bugs.
We made an agreement with the business that only show stopping bugs (Blockers) could interrupt a sprint. When a Blocker comes in, it gets immediate priority. It isn't estimated and isn't even part of the official backlog. It is side work that has to be done and impacts the team's capacity.
All other bugs get assigned to the backlog. We run in two week sprints and have at least two teams per feature area so there is always a team starting a sprint every week. These bugs get groomed and estimated per normal.
With Jira we maintain a separate "Defect" backlog (specifically issues found in production). This backlog is groomed by a triage team and then all feature teams have access to it. During sprint planning teams are instructed to take roughly 20% of their capacity if Technical Debt. First priority in Tech Debt is always current production defects. This usually translates to our teams working on 1-2 bugs a Sprint, in addition to their new feature work.
New User Stories pulled into a sprint - ALWAYS ESTIMATE
A healthy product backlog should have two to three sprints of "Ready" work. That is stories that meet the INVEST criteria for a User Story. If you don't have this, then that's a bigger issue to tackle, which will make your team much more effective.
If you don't have a well groomed backlog, then what you want to do is take the time to groom new stories. If you are halfway into the sprint and there is no work to be done, then have a one hour meeting and groom the very top of the backlog.
This is critical, not just because you want all stories estimated. Taking in a story that is not fully defined is a great way to waste effort.
- The Story could not be important anymore
- The story could be ill defined and a lot of time wasted on re-work to meet "Done"
- The story could be ill designed and lead to bugs in the system.
Poorly written user stories can take up to 24x longer to fix, than they took to write the first time (based on research by Jeff Sutherland).
Beyond the above advice, the single biggest thing I would recommend is holding regular Backlog Refinement Meetings. The Dev Team and the Product Owner working together to ensure your stories meeting the INVEST criteria. A lot of teams are used to having a "Definition of Done". You also need a "Definition of Ready", what does the story have to have before development can be started.