3

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)?

  • 4
  • 1
    @ThomasOwens this is bit different issue. At the end of the sprint the team is figuring out that original estimate was wrong and in fact it will need more time to finish the task. At the same time task was not delivered so was moved back to product backlog. Should we then re-estimate task and higher the size of it as we know at that point that it is bigger than originally thought. – codewarrior Aug 18 '15 at 12:19
  • I don't see how this is any different - I know that my answer to the proposed duplicate applies to this situation. You do not reestimate the story. It doesn't matter why you didn't finish the story (you underestimated it and didn't plan enough time, other tasks came up that pulled people away, your team got sick and was at diminished capacity for 2 weeks, or any other reason), you handle it the exact same way - move it to the product backlog, prioritize it, and finish it when it comes up. It is worth the same number of points as the original estimate. – Thomas Owens Aug 18 '15 at 12:22
  • @ThomasOwens why it is worth the same number of points as the original estimate? – Bartek Kobyłecki Aug 18 '15 at 12:42
  • 2
    I think the answers to my question pm.stackexchange.com/questions/15707/… are generalised enough to apply here too unless anyone can see a very distinct difference that I can't? – Willl Aug 18 '15 at 13:11
2

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.

  • 1
    I think this is an excellent answer. It shows a level of pragmatism that is essential. also it highlights the learning a team can gain from realising that they might have not fully broken down a large story into smaller stories. – G.H Dec 4 '15 at 8:32
1

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.

  • Hi & welcome to PMSE. Just for your information have a look on the tour page to see how this site works. – Tob Aug 19 '15 at 5:40
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.