Do you re-estimate your story points during the sprint?

I found this interesting discussion on Linkedin and I want to share with you

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.

Share:
Mario Lucero

Mario Lucero

I am all about helping companies to adopt agile as methodology in Chile.

Why?

I believe many organizations think that agile is not for Chilean companies because of Chilean culture is totally
different from i.e. USA culture but I worked with Chilean professionals who after using agile realized it is feasible
to implement it.

Agile works in small and large projects and there are many evidences which demonstrate this.

1 comment

  1. I just want to say I’m beginner to weblog and actually loved you’re web page. Very likely I’m going to bookmark your blog . You really come with terrific articles and reviews. Thanks a bunch for sharing with us your website page.

Leave a Reply

CommentLuv badge