Many projects re-estimate user story effort during iteration planning. Why? It adds no value to the customer waiting for the work.
All story point estimates 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 up 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 no matter how the figures were cut the burn up 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.
Trap: Never re-estimate effort for stories that have already been sized. Determine complexity for new stories only and always with respect to existing features, otherwise the burn-down chart will be skewed in favor of early work. Re-estimation doesn't help software get delivered any faster so it's an activity to drop from the process to make it leaner.
