What happens to Product Backlog Items that you can’t complete by the end of the Sprint?

I have read so many articles that say you should never re-estimate unfinished stories based on just what is left as that will affect the velocity when they are finally finished and render the team's velocity less accurate. If I'm reading what you are saying here correctly, you are saying that you should do the exact opposite. Can you elaborate on why you think this is good practice? As a Product Owner this is a topic near and dear to my heart

There are a lot of opinions on this topic; and I do believe that re-estimation can be overused. The Scrum Guide does not give an opinion on this point, because using points to estimate is a complimentary practice. The Scrum guide states "The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration."

Some examples of when not to re-estimate:
- You should not re-estimate based on WHO the Product Backlog Item is assigned to; estimation is a means of conducting relative sizing. Whether the story is assigned to a senior developer or a junior developer makes no difference. Points estimation is intended to be used to size stories relative to each other.
- After a story has been completed or after a story meets the definition of 'done'

* Note: Velocity is the great equalizer; it does not matter if the team consistently over estimates or under estimates their work; what matters is that they are consistent. If a team is using points to estimate their work, then what matters it the relative sizing of PBIs to each other.

When to re-estimate:
- If the relative size of the story has changed

The question of whether to re-estimate a partially completed story should be based on team agreement. Some teams may decide to give partial "credit" to the previous sprint and others may take an all or nothing stance on giving credit to the previous sprint. Some may re-estimate the remaining work for transparency purposes, so that the Product Owner has a more information to use to determine how the remaining work should be ordered on the Product Backlog. The point I was most hoping to make is that uncompleted Product Backlog Items should not carryover by default into the next sprint; but instead, the Product Backlog Item should be returned to the Product Backlog.

I recommend Mike Cohn's excellent book "Agile Estimating and Planning" for a fuller (and readable!) discussion on estimation for Agile teams. His opinion is that if an uncompleted story is not completed in a given sprint and is not going to be taken up in the next sprint, it should be re-estimated. I agree that PBIs which are returned to the Product Backlog should be re-estimated according to the team's Refinement process.

If a Scrum team consistently has a large amount of work which does not meet the definition of 'done' by the end of the Sprint, then this is something that the team should be discussing at the Sprint Retrospective.

I’d agree that stories which are not completed and then placed in the backlog for further discussion should be repointed by the team at a later date.

In my experience, teams which “cash in” partial stories have all sorts of interesting side effects, most of them negative. If nothing was actually delivered, how can any credit be claimed? In practice, every story could have “partial” work done at the end of the sprint but nothing actually delivered. To me, that smells a bit.

Good answer and agree with it. But still this is a controversial topic. Let´s assume that 70% of the PBI work has been done and therefore I must send it back to PB to be re-prioritized. Let´s say that the PO really loves this item and want it for the next sprint. By your answer we must re-estimate the PBI and now this item only count as 30% of the total amount of effort and that´s how it´s going to be related as the output for this sprint. What I´m gonna ask is, what about the other 70% of effort, where does it goes? How to keep track of the whole effort for this PBI in order to not lose this info and also money?

The more important question is "Why was the work not done?" It is this question that the team should discuss in their next retrospective.

However, you are right that the team does need to agree upon an approach for PBIs that do not meet the Definition of Done by the end of the Sprint if they are using the complimentary practice of estimation. If the team is using the complimentary practice of team agreements, then the approach can be documented there.

I recommend an all or nothing approach. In this approach, PBIs that do not meet the Definition of Done are returned to the Product Backlog without giving "credit" to the current/previous sprint (no points applied to the current/previous sprint). The PBI should be re-estimated as part of the team's Refinement process (e.g. the PBI may be re-estimated at the next Refinement meeting). This is my preferred approach because it has the maximum amount of transparency and the least administrative burden of any of the options. It also preserves the team's Velocity to show only the amount of work that a team can actually get to Done in a Sprint.

Some team members may express concerns with this approach, since they may feel that they are not getting "credit" for their work. They should be coached to understand that Velocity is a tool for the team to understand how much Done work they can complete in a sprint. (As the Scrum.org Glossary states, "Velocity: an optional, but often used, indication of the amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Developers for use within the Scrum Team.") If work that did not meet the Definition of Done were added to the team's Velocity, then Velocity would no longer be an accurate measure of how much Product Backlog was turned into an Increment of Product. Additionally, Velocity should not be shared outside of the team and therefore it is not something that they need to worry about getting 'credit' for. There is really no need to worry about losing the information as to how much of the work or what % of the PBI that they did complete - the point (pun intended) of Velocity is to track the amount of Product Backlog that is turned into an increment of Product during the Sprint so that the team can use that as a guide when determining how much work to pull into the next Sprint. If Velocity is polluted with undone work, then it becomes a less useful, less transparent tool for the team.

I agree! "cashing in" on PBIs which do not meet the Definition of Done pollutes velocity and makes it a less transparent tool for the team. See my response to Eber above. The point of Velocity is to track the amount of Product Backlog that is turned into an increment of Product during the Sprint so that the team can use that as a guide when determining how much work to pull into the next Sprint. If Velocity is polluted with undone work, then it becomes a less useful, less transparent tool for the team.

why does it say: "the Product Owner and the Scrum Team"? isn't the product owner part of the scrum team?