Re-estimating during the Sprint
If the sprint goal becomes obsolete, sprint will be cancelled. All incomplete PBI’s are re-estimated and put back on product backlog.
Now consider a scenario where a team crafted a sprint goal and working on it. Let’s say team has created 2 items (User Story’s or tickets whatever) to deliver the sprint goal. During the sprint, PO got a change which is not impacting the sprint goal but a slight change in direction. With the new change, only half of the work in each item which is completed is valid and remaining half which is yet to be started is no longer required. (for ex UI changes in each story are done and valid and back end changes are not yet started and also not required. Pardon me if you feel the ex is bad 😊).
Option 1: Do not re-estimate the items. Update the acceptance criteria and accept those as it is potentially releasable. Accommodate the new change as team has more time and capacity available.
But in this option, the total work done by the team is not reflecting in the sprint. Less work done but more story points given indicating lack of transparency. Impact: If this is happening often in this VUCA world, how can PO plan the release as velocity is not giving the right projection with bloated numbers?
Option 2: Re-estimate the items. (obviously, it will be sized small when compared with previous). Accept those as is. Create a new PBI to tackle the new change, size it and accommodate in the same sprint.
But this is against the fundamental – do not re-estimate during the sprint. But here in this case, if we go with option 2, is it not bringing in the transparency and predictability?
First of all, there is no fundamental of not re-estimating during the sprint. Where in the Scrum Guide does it say this is not allowed?
Re-estimating can be seen as part of the team modifying the sprint backlog throughout the sprint. It depends on context if it is a good approach!
The general question to ask is: how does the team feel about this? What do they want?
Personally; my gut feeling without context, if the change in direction is big enough to valid re-estimation, you should do so for the sake of transparency. Any metrics or statistics going off the charts because of this, is fine, because they clearly indicate the impact of the change in direction (hence: help transparency).
When it comes it comes to your argument
how can PO plan the release as velocity is not giving the right projection with bloated numbers?
I would say: release as early and often as possible without explicit planning ;)
But this is against the fundamental – do not re-estimate during the sprint. But here in this case, if we go with option 2, is it not bringing in the transparency and predictability?
I would hope so. Why is failing to achieve this transparency and predictability "fundamental" to your way-of-working?