Re-estimating stories during play - cone of uncertainty

Cone of uncertainty:

At time zero, we are at our maximum uncertainty about how a feature will be delivered. As we progress toward delivery, we learn more about the problem and hopefully its solution. As such, we are better equipped to provide increasingly accurate estimates as we approach delivery.

With this in mind, cases arise when stories need to be re-estimated after they're in play. I lean toward keeping the old estimate and recording the new estimate at the time it becomes obvious that the story is bigger/smaller than originally thought.

One of the questions often asked is whether we can defer re-estimation until after the story is delivered? This should be avoided for a few reasons:

1. We need to capture the number of times a story was re-estimated and why. 
2. Stories that have been re-estimated several times draw attention to themselves and should promote discussion about estimation, way the story has been broken down and other processes that support an iteration  and velocity.
3. Its important to encourage good estimation - avoiding re-estimation at the time it becomes obvious is counter productive to this goal. Further, several re-estimation attempts during a story is usually something a developer will try to avoid - it's a pride thing - as we inherently know this is bad.

During iteration planning and estimation, previous iteration stories, that underwent re-estimated, should be discussed before the team estimates new stories in an attempt to improve the estimation process.