A lot of projects re-estimate story effort during iteration planning.
This is of limited value because all story points will (on average) be the same percentage incorrect by the end of the project depending on the complexity of the work, the programmer, or other environmental factors. A change to the estimate won't alter the fixed project delivery date and may even skew the progress reporting; tasks in iteration one don't have the benefit of hindsight.
Re-estimation won't benefit burn down chart reporting either because it doesn't substantially alter the shape of the graph or the fixed finish date. Some tasks will be easier and some will be more difficult but the average accuracy of estimation will be the same.
For example:
Project XYZ was estimated as a total logical effort of 1000 story points prior to iteration zero, loosely based on 500 days of actual effort.
By iteration four it became clear that the estimates were quite wrong; the project as originally scoped would need about 100 days of additional effort to complete and many features were descoped to meet the go-live date.
Adjusting the points for each story did not help deliver the remaining functionality on time because the burn down graph remained the same shape. Pausing to update story points just delayed the programmers even further.
Since most of the story “effort day” estimates were 20% lower than they should have been it was better to leave them as they were and get on with development.
Exception: this rule still means developers should gather to discuss stories at the start of the iteration. Iteration planning meetings are a good forum for communication and ideas. It's simply means there is no benefit playing estimation poker again to adjust complexity.
