reestimating story size after moving back to product backlog

Question

Let's assume that part of the story (worth say 8 points) was done in the sprint 1.

Then, after implementing part of it we are discovering that in fact it is much bigger than originally estimated. Credit for completing the story was not given in sprint 1 (story was not completed) and it was moved back to product backlog.

• Now, should we re-estimate it during the planning for sprint 2?
• Should the estimate contain ONLY remaining part of the story (part was already done in sprint 1) or the total size of the story (then implemented part should be reflected in team capacity so that more stories will be taken to the next sprint)?

If we use the later approach what with other stories which are there in the product backlog and were estimated based on the story which was re-estimated (aka the size of this next story was similar to the one that was re-estimated and that's why next story has some particular size). Should we change estimates of all such a stories as well? This seem to be quite a big overhead.

If we use the first one then we know straight from the beginning that our velocity current sprint (sprint 2) will be much lower than usual as the story is having inaccurate estimate (and we already know it during the planning).

What should be the best approach here?

To clarify what I mean by re-estimating. I don't want to move only part of the work which was not done to the next sprint, but in fact we've figured out that our original estimate was wrong. Should we so to say change the estimate to 21 instead of 8 and agree that half was done in sprint 1 and we will have to spent time needed to develop remaining 10-11 story points in the next sprint (sprint 2)?

Answer 1

First, you can re-estimate the user story, since it was not delivered.

Second, you can break down that user story into valuable and working pieces. You estimate the pieces and deliver them. This approach is a bit better in the long term, because your team will learn how to break down work to smaller pieces, which is faster to deliver and therefore the feedback comes faster as well.

Answer 2

if the programmed part of the story has customer value and can be released you could give your team the estimated story points and create a new story for the missing part. Then it is also not necessary to plan it for the next sprint.

If the programmed part is not releasable there is no point for the team and the story keeps its original estimation. The team gets the complete package of points when the customer value is delivered.

Answer 3

After starting to work on a story, you should not revisit the estimate that you gave off for a story.

Estimates are always based on incomplete information are almost always inaccurate. In the long run, this doesn't matter, because estimates tend to be either too low or too high, but rarely (especially in story-point estimations) consistently skewed to one side.
This means that the error in the estimation on one story will get cancelled out by the error on the estimation of a different story.

Also, if you start to re-estimate the work that you didn't finish in a sprint, why not re-estimate the work that you did finish? Perhaps it wasn't the wrongly estimated story that got carried over, but a different story that couldn't be completed because there was no time left.

---

What you can do with stories that get carried over from a previous sprint is to make an assessment of the amount of work left open in the story, so that you can pick up enough new work to keep the team occupied for the whole new sprint.
This assessment should be done when planning the incomplete story in a new sprint, but the new "estimate" given there must only be used for planning purposes and not be made visible or public in any way. When completing the story, the team will just receive the original estimated points.

Whether or not you do the 'remaining effort assessment' on incomplete stories, there will be an effect of not having completed a story on the velocity that you reach in a sprint. This should not be a problem, because the velocity of a single sprint doesn't really give you any information. Most of the information can be derived from the trend in the velocity when looking over a larger period.