Re-estimation of PBIs at Sprint Planning

If a PBI does not comply with the DoD by the end of the sprint then it should not be included in the increment and should be placed back into the Product Backlog and re-estimated.  The PO and the sprint goal will determine if that PBI is required for the next sprint or not, in which case it may require re-estimation during sprint planning even if it was re-estimated when placed back into the PB at the end of a previous sprint. 

The objective of sprints should not be to chase or beat any velocity numbers. Sprint is a time box container to meet a short goal of a product/service.

If developers want to break the story just for velocity purpose, then it will create silo mindset between the ones who do programming and the ones who do testing in the team. The programmers want to take credit for their part of work and not to be responsible for a backlog item when it is not 'Done' in a sprint. Also they will be missing the opportunity to inspect and adapt the DoD.

Estimates are a tool for the Developers to be able to determine how much work to pull into the Sprint. They aren't for the Scrum Master, the Product Owner, the developing organization, the customer, or any other stakeholder. I'd let the Developers decide if they want to reestimate or not. However, if I were the Scrum Master for this team, I'd observe how the team used their estimates and understand any limitations or the cost/benefit of spending time to reestimate to make sure that the team continues to believe that the time spent reestimating work is useful and valuable.

Velocity is the rate at which work is Done. I'd therefore wonder about what the Developers are trying to measure and why.

The purpose of estimation is for Developers to get their arms around how much work they can take on, so a valuable increment may then be produced. Who wants this "count" they are concerned about?

It's always interesting getting to know new points of view, so thank you everyone for your comments! 

I apology, I maybe was not clear in explaining my doubt, so I will try to explain that differently. The point is that I do not fully disagree with the idea that re-estimating would "fake" our estimates/velocity as they say, while at the same time I believe we have to re-estimate to better know how much we can try to add to that Sprint. At the end, I let them have the final word about re-estimating it or not, I just want to try to help them and guiding them in the best way I can.

At the moment, I do not think that there is one person who want this "count", still it is something which is transparent outside the team (is that wrong? At least it is not used to compare teams, as far as I know). However, we are under an Agile transformation (from previous project mindset) and, maybe due to "deadlines"/pressure from outside the team, they always agree to "over commit": e.g. if our velocity is 10, they agree to go for 20, also because in this 20 they consider that "it would be actually less than 20 because some work has already been started or ready to be tested" (I see some loss of transparency here). Perhaps they do not consider "estimating" worth. Anyway, in their opinion re-estimating and reducing the initial estimation would make "some points get lost", so above all in an prevalently output - not value - oriented context, that can be considered "important" (perhaps to chain the next project right after).

Perhaps, as usual, there is just no "one answer"/"good practice" here, since every team and context are different.

Whenever a given item has been started during the last Sprint and it should be part of the next Sprint

Was the increment "Done"? If not "Done", then your velocity is zero, yes?

Yes. Stop communicating the velocity and the estimates to outside the team, and communicate only the Sprint Goal.



Then they can define a good Sprint Goal and attempt to achieve that.

By using Story Points as the metric of your velocity, you are measuring based on a guess.  I challenge you to look back at stories you have completed, find all of them that were of the same points, then determine if they all took the same amount of time/effort to complete.  The estimate is made using the information available at the time of the estimate.

Estimates are to help the Developers determine if they feel like that can complete the work they pick as their Sprint Backlog. As soon as work begins, those estimates are useless because new information will be discovered. 

Since you stated that a transformation is underway, I suggest that you start looking at other metrics as well.  Estimates are leading indicators.  Lead Time, Cycle Time, and Throughput are trailing indicators.  They will show the actual time it takes to move an item to Done, actual number of items that you are moving to Done in a period of time.  Those can be better used for forecasting.   I suggest that you read the two books by Daniel S. Vacanti that are found at this link. https://actionableagile.com/resources/.   They can help you to better understand a way that your organization can be better at forecasting and predictability.