When should you re-estimate in Scrum

If we know one thing about estimates, it is that they are wrong. That’s okay, if they were correct we’d call them actuals. However estimates can be useful to help with some level of planning. Given that scope and requirements change all the time, we often get asked when you should resize items in Scrum, and when you shouldn’t. Also note you should be splitting stories and sizing BEFORE the sprint in backlog grooming/refinement. We encounter many teams that only size items in Sprint Planning. This is too late for you product owner to make priority decisions based on sizing.

Here are our guidelines on when you should resize:

• If you split a story into smaller stories, you need to resize each of these smaller stories you split the original story into. Also remember that the new stories don’t need to add up to the original story size. Once we break things down we generally get a much better idea of the size, since we are better at sizing smaller things than large things. It’s very common for the total size to get bigger when we break things down.
• If the team made an assumption when sizing and that assumption has now been shown to be incorrect. For example you assumed the same functionality is available on all platforms, and after research that turns out not to be the case.
• If your understanding about the requirements have changed, you should resize it. Often we find that teams didn’t ask enough questions in grooming initially and thought they understood what was expected, but later they realised they misunderstood something. Even if the requirement hasn’t changed, the team’s understanding of the requirement may have changed.

And maybe more importantly when you should NOT resize:

• When the team gets faster or slower. The simplicity of sizing in story points is that the link of effort to time happens as an observation (how many points we DID), rather than an estimate (how long do we THINK it will take), as a result there is no need to re-estimate. You can just recalculate release dates based on your new velocity. However, we often see new teams inflate story points because they don’t complete as much as they initially expected.
• If the scope of a story changes, but the change is small enough that it doesn’t impact the size of the story, hopefully it goes without saying that there is no need to re-estimate it.
• Don’t resize after you have started working on a story. If you are mid-sprint and you uncover something that drastically would change the size of your story – talk to your PO. It’s their decision whether or not they still want this feature. Rather split that new discovery into a separate story and size it on it’s own. Also bring this up in your retro. Why did you only discover this mid-sprint? Is there a way to potentially highlight this earlier next time?

For more on this topic take a look at: http://www.mountaingoatsoftware.com/blog/to-re-estimate-or-not-that-is-the-question