I found this interesting discussion on Linkedin and I want to share with you
Murilo Lessa Software Engineer at Ticketmaster Top Contributor
During Release Planning the team estimate user stories points, (we do not estimate tasks, but we do slice). It can happen sometimes that while working on the story the dev/team realizes the story was smaller or bigger than initially predicted (might feel like an 8 and not a 5, for example).
The SM argues that we should not adjust/change points during the sprint, even if the story proves to be small/bigger than predicted since we learn with the experience and it would not affect our metrics in the long road. On the other hand, the wrongs points were due to lack of knowledge so the only thing the team might be learning is that they should always estimate high in any scenario since they can be wrong again, plus they do affect the metric since they imply a “size” (effort, …) that is not real.
What is your view on it?
By Brett Maytom Professional Scrum Trainer
The short answer is no. i
Do you want a) a perfect report or b) a product?
When has an *ESTIMATE* become and actual number? If significantly different and going to impact the sprint, talk to the product owner.
Remember the agile value of collaboration over contract negotiation. Adjusting numbers sounds contractual to me.
By Skunk Savaliya Certified Scrum Master I Agile Professional | Project Manager
I agree hands down that we do not change story points, but I would like to cite a scenario from a company that billed on story points. So here is that they did – They maintained team estimated SPs and what they could mutually agree to billing. Hence, if a story was estimated at 5 story points but turned complex to gain 13, the billing would be for 13 while the team would still see 5 on the dashboard. It could be inclined both the ways.
Soon they realized there were a lot of conflicts so they started billing on percentage i.e. each percent would have dollar value against it and there were slabs to reward high performance (and low payouts for poor performance).
Mario Lucero Agile Coach
If you have wrong estimation the Retrospective is a good place to take an action item to figure it out the problem. Indeed, I had this issue with one team and in the retrospective we add the QA effort which wasn’t taking into account in the planning poker game.