To Re-estimate or not to Re-estimate

Agile projects are incepted with a story list that has all the stories estimated. The team has completed 4 iterations and there are 8 more to go. The team also has usual churn of people. Are you in favor of or against re-estimating stories during next sprint planning? Practitioners are on both sides of the fence on this one. Some recommend re-estimation and some want to stick to the original estimates. A colleague of mine recently explained why he is not in favor of re-estimating. He said, "I don't want to have to explain to the project sponsors why the project estimate just changed from 133 points to 97. Do you think the scope has changed?" That was a very insightful discussion. He then said that if the team is not finding the big stories as big as they initially thought, it won't matter. That simply means the team is now burning more points of a larger scope number. This will proportionally be the same as burning less points of a smaller re-estimated scope.

Why Re-estimate?

Re-estimation is a tough thing to convince people on. I still see a huge benefit in it.

  1. The idea of re-estimation is not about lowering or increasing the numbers; it is about estimating the relative size of the stories.
  2. The stakeholders/sponsors, ideally, should not be concerned about total point scope. This is an internal number for the Dev team. Sponsors should just be concerned about the rate of progress towards delivering a product.

As a sponsor, I'd be more interested in the secondary estimate, i.e. time. When will my product be ready for release? It really doesn't matter if this scope is estimated at 150 points or 800 points. Re-estimating the stories should be encouraged because it:

  1. Keeps the relative size of stories up to date,
  2. Makes it almost mandatory to revisit the release plan, and
  3. Promotes conversation.

Relative size is a big thing to watch out for in situations where new stories are added or existing ones are split. The reality of Agile greenfield software development is that the initial brainstorm hardly ever reveals all the stories. Total effort, as estimated, at the beginning of the project will most likely change (increase). An initial estimate that is not changed with the lessons that have been learnt in the last few iterations is not acknowledging that:

  1. Work done in the last few iterations can be leveraged,
  2. Assumptions during initial estimates may have changed.

Typically, teams start with developing the simplest functionality first. Let's assume that Story A is the simplest functionality and is 1 point. And, the initial estimates had story B estimated at 3 points thinking that this is three times the effort of A. Why would I not want to re-estimate B as a 2 if I now know that it is twice the effort of A and not three times the effort?

One of the biggest benefits of re-estimation is that it reevaluates a team's progress towards the end goal and indicates if you are on track or not. Not re-estimating will increase the probability that one of the stories a few iterations down with an initial estimate of 2 points will now take 5 points worth of effort. There may be many more such sitting in your pile of stories.

On big projects where number of stories for each release easily run into hundreds, the variance amplifies. The benefits derived from re-estimation may not always be so obvious, but they for sure increase the level of comfort and confidence in the team.
Picture taken from: http://www.stellman-greene.com/blog/wp-content/uploads/2007/05/schedulereview13.jpg