Difference Story Points - unfinished User Stories
Hello everyone,
I have a question about unfinished user stories. If a story is not finished in the sprint, it goes back into the product backlog and is re-estimated. If a story had for example 13 story points before, but was now re-estimated with 8 story points and comes into the next Sprint Backlog, what happens with the difference of 5 points? These are actually lost and "break" the velocity. Can you tell me something about this?
Thanks in advance :-)
This is not an uncommon concern. Rather than worrying about lost points, I would encourage teams to think about what they need to do in order to effectively plan a Sprint. Estimates, if a team is using them, should be used to help a team determine if the work that they are planning for a Sprint makes sense given the team's capacity to do work. In that sense, it doesn't matter that points are being "lost", since the team is saying there are 5 points of work left and knowing this can help them determine if it makes sense to bring in a certain amount of work into the Sprint.
However, I'd also suggest that spending so much time talking about estimates is wasteful. If so much time is being spent estimating, reestimating, and debating the estimation process, perhaps there is a better way. Focusing on the smallest feasible slices of work and the flow metrics tend, in my experience, to be much better than using story points since it focuses on understanding the work, decomposing the work, and determining actual working time to get work to done rather than guessing about the future.
These are actually lost and "break" the velocity. Can you tell me something about this?
Actually it doesn't break velocity, it is telling your Scrum Team the truth. In Scrum one of the most important concepts is to have a Done, valuable and useful product Increment every Sprint. So velocity indicates how much the Scrum Team was able to get Done. The 13 point PBI is either Done or not. Almost doesn't count. Partial, undone work is not part of the product Increment.
As Thomas points out, lost points shouldn't be the main worry. The focus should be around why the PBI wasn't completed and how to improve next Sprint.
From the Scrum Glossary:
Velocity: an optional, but often used, indication of the amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Developers for use within the Scrum Team.
Okay, thanks a lot for your perspective. I've just started working in a Scrum project and should look more closely at velocity. But of course it also makes sense to focus more on why a story couldn't be completed and work on those reasons, you're right!
If a story had for example 13 story points before, but was now re-estimated with 8 story points and comes into the next Sprint Backlog, what happens with the difference of 5 points? These are actually lost and "break" the velocity. Can you tell me something about this?
The only purpose of estimation is so the Developers can get their arms around how much work they can take on in a Sprint. Everything else resolves to value and empirical process control. So the velocity ought to tell the truth about how much work they can actually complete. Velocity is the rate at which work is Done, not part done.
In terms of story point accountancy -- and we should not be story point accountants in the first place -- the work remaining in the Product Backlog will have been reduced by 5 points.
Going to try and do this without getting on my soapbox.
Velocity based upon Story Points is totally useless. You don't complete Story Points, you complete Stories. Story Points are just estimates made at a point in time based upon the information you have available. They are nothing more than a guess. Typically as soon as you start working on a story, new information is gained that could impact your estimate.
The estimates can help Developers in determining if they feel like a body of work can be done during a Sprint timebox. But once work begins, those estimates are no longer useful. At that point, it is work completed that matters. If a portion of that work is not completed and the Developers feel that it is useful to reestimate, then let them do it.
The words velocity and estimate do not appear anywhere in the current Scrum Guide. The word size is used twice in the section that describes the Product Backlog. However, no guidance is provided on how to size items. That is left to the team doing the work to decide.
The important thing for a team to focus on isn't how many story points they complete in a Sprint. It is how much incremental value is being delivered to the stakeholders of the product.
I'm going to leave this here as a little light reading. It is an article by Ron Jeffries who is credited with creating Story Points. Knowing the history behind them can sometimes help you better understand how to use them. https://ronjeffries.com/articles/019-01ff/story-points/Index.html