Re-estimating user stories in a Scrum team
When working with a Scrum team as an Agile Coach or Scrum Master, I inevitably run into the question what to do with
user stories that are ‘left over’ (not completed) when the sprint ends. Should they be re-estimated (also often referred to as resizing or re-Pokering)? And if you re-estimate them, what happens with the difference in story points between the original estimate and the new estimate?
Some people always re-estimate any user story (or other product backlog item), other people prefer not to. I think you should always re-estimate. The difference between the original estimate and the new estimate will not be added to the velocity of the first sprint, those points will ‘disappear’.
A simple example
You just closed up sprint 10. One user story was not completely finished. The original amount of story points for this user story was 8 points. In order to plan sprint 11, the leftover work is discussed within the team and the story is resized afterwards. The team now estimates that there is still 5 points of work left. If the story gets finished in sprint 11, the 5 points will contribute to the velocity of sprint 11. The ‘missing’ 3 points will not be added to veloctity of sprint 10.
Let me explain why
-
-
- The velocity of each sprint is based only on the story points of the user stories that were completed in that sprint. Any story that is half-done will count for 0 points, even if that story gets finished in the next sprint. After all, we created 0 business value in that sprint as well (with respect to that story at least).
- I also do not want the ‘missing’ points added to the next sprint, as it is important to have the velocity based on only what was accomplished in that sprint. Not on what was accomplished in the previous sprint (or even earlier, as some stories get dragged from sprint to sprint).
- From a statistical point of view by the way (calculating velocity and doing projections on what we can do in a couple of sprint from now is actually doing statistics), each measurement (being the velocity of one sprint) should be independant from all other measurements).
- If you do not resize the user story, how will you know if it fits in your sprint? Let’s say your velocity is 25 points. You are in sprint planning and you already planned 20 story points of ‘new’ work in your next sprint. If you do not resize your old story (of 8 points), how would you know if it still fits?
- Looking at the psychological side, I find that not resizing the story and ‘just’ adding the points to the velocity of the next sprint gives the wrong signal. Of course, story points are not a reward for the team, but just adding the points to the next sprint hides the reason for the story not being completed. The team committed to deliver the story. The story did not get finished. Either there was an impediment that prevented the team to complete the story (which should be addressed) or something else went wrong (which is perhaps something to discuss in the Retrospective). Either way, adding all of the points to the next sprint (with the argument that it is ‘averaged out’ anyway, as I hear often) will not reinforce behaviour where the impediment is addressed or where the team reflects on what went wrong.
- The arguments above assume that after resizing, the story is smaller (5 story points) then before (8). However, this is not always the case. Some stories actually turn out to be (much) more work then initially estimated. This is unfortunate, but it happens occasionally. If we do not resize the user story, we would lose an important opportunity to discuss the remaining work and find out that the story was much more work then we thought. Instead we would add the story ‘blindly’ into the next sprint and possibly fail again at delivering it into the next sprint…
-
Of course you don’t have to agree with my reasoning. But if you ever find that your team has trouble because stories keep getting carried from sprint to sprint, give resizing stories a try. And let me know how it goes! 🙂
by Jasper Verdooren