Stretch "Goals" and "Stories" are they part of SCRUM ??

I keep reading about stretch stories and goals being introduced in the sprint.   

Is this a normal part of traditional SCRUM or  just another  hybrid process being introduced within scrum practices  by the Dev Team ? 

Well...from experience and in my opinion, it is a way to squeeze as much work as possible into a Sprint. Scrum doesn't say you can't take more work than the work that already would meet the Sprint Goal, however, the real question is, Is this a sustainable practice? Will people burn out?

Those are not part of the Scrum Framework. They are practices and processes that a team may choose to add to the framework in order to help them produce a working Product Increment. 

it is a way to squeeze as much work as possible into a Sprint. Scrum doesn't say you can't take more work than the work that already would meet the Sprint Goal,

So would this be done independently  by the the dev team or in consultation with PO ?  As for the burn out I trust the team knows it capacity / limitations.. 

I ask this question, because at times  dev team are over estimating story points and then find that WIP bin is empty sooner then later.  This happens  ( by trending) approx every  3rd/4th sprint cycle.   

What is the best practice to  eliminate any "stretch"  items into the sprint ? 

Minor tangent... I would caution against the assumption that they would know it's own capacity/limitations. They oftne don't. It's through the awareness are care of the Scrum Masters that questions to the team health ever occur. Members of the Dev team are naturally inclined to always need to feel valuable to the organization and working harder not smarter is rewarded, unfortunately. As a side effect, more often than not teams are over-estimating because conservatism is negatively viewed. 

Keep in mind that Scrum is a process framework. You apply the framework onto existing processes and make improvements to those processes. Scrum guide never mentions Story Points or Velocity for this reason. As you know, the next step is to improve the processes (hence why your question was asked) and to best take that step, consider the causes behind the over-estimations and collect some trends of the team.

• How many Sprint Goals are achieved and how many Stretch items are achieved, Sprint by Sprint?
  • Are Stretch items being worked before items dedicated to the Sprint Goals are complete?
  • Do they know they are over-estimating the Stories or over-estimating the Sprint?
    • If it's the Story, have them evaluate what changes during the Sprint?
      • How vague are the Value Statements?
        • Do the Acceptance Criterias properly reflect the Value Statements?
      • Do tickets suffer from scope creep?
        • For every bit of scope creep encountered, have the story updated separately and run a query on the number of stories completed and how many of them encountered the creep.
      • Are there handoffs for each piece of work?
        
         
    • If it's the Sprint, go through Planning as normal but only build the Sprint with Sprint Goal items and ask them to pull any piece of work into the Sprint once all Sprint Goal work is complete.
      
       
• Are they approving the plan because they feel the certain bits of work are required of them in that particular Sprint?
  • If so, where does that feeling come from?
    • Are the members writing the Sprint Goals? 
    • Is the PO pushing work to the Dev team?
    • Does Dev team control the estimated delivery time frame?
      
       
• Are they approving the plan because they truly feel the load felt appropriate during Sprint Planning?
  • If so, what changes during the Sprint?

If a team believe they can take on more work than they have done in previous Sprints, they may choose to increase their capacity.

They can use “stretch stories” instead, if they really want to, but doing so is unlikely to improve predictability. It also implies that if extra capacity should ever exist, it ought to be spent on completing more backlog. Perhaps the available time would be better spent on other things, such as improving the team’s process, or chilling to avoid burn-out.

Thank you all for the feedback !!