"95% done item" and velocity calcatuion

Hi Bartosz, Story points reflect work not done (yet), so I would say, the PBI points are reduced to 1, before selected into the next sprint.

The next sprint of 2 PBI's will be of 21 points, not 30.

The velocity of the first sprint will not be 20, but 10. Because the 10-point PBI was not "Done" at the end of the sprint.

You will only see this as a loss, or as slowing down, if you are using story points as your measure of progress in sprints.

Talking about this, Bartosz, what is the only measure of progress?

But since the total (story point) size of the product backlog is reduces, the "amount of work not done" of the Product Backlog is reduces, therefore, no loss or slowing down there.

So it all comes down to how you measure and present velocity and/or progress.

Related to this; if you want to avoid these (huge) differences in points done per sprint, it is a very good practice to slice stories into smaller pieces, and to have those smaller pieces be Done in the end

I am aware that velocity calculation is just a tool to help, and shouldn't be measured as detailed as possible since it's never 100% correct, but how would you mitigate the effects of the abovementioned situation just to have a better picture on overall performance?

Were the team still able to meet their Sprint Goal, and deliver an increment of release quality? Isn't that how performance ought to be gauged?

Thanks for your answers!

For this particular question, I thknk that:

" But since the total (story point) size of the product backlog is reduces, the "amount of work not done" of the Product Backlog is reduces, therefore, no loss or slowing down there. "

ends my doubts.

And yes, I am aware that achieving sprint goal is usually a more relevant factor when measuring "success", I was just curious about your thoughts on ths paricular example in this particular metric :D 

To provide my opinion let me pose a scenario.

• Sprint A has two 10 point stories, 20 points total. 
• One story is completed the other is 95% complete.
• The incomplete one is put into the Product Backlog and re-pointed to 1. 
• Sprint B consists of two 10 point stories and one 1 point story, 21 points total.
• The 1 point story is completed, one of the 10 point stories and the other 10 point story is 75% complete.
• The incomplete story is put into the Product Backlog and re-pointed at 3.

Is the velocity in Sprint A 10 points or 19?  Is the velocity in Sprint B 18 or 11? Do you get partial points for the stories not completed?

An estimate is for the completion of a story.  If it isn't completed in a single sprint does it really change the estimate?  If so, why don't you re-estimate stories in the current Sprint based on new information found while working on the story? 

I realize that the team should be able to provide an estimate of the work remaining during a Sprint.  But Story Points are a method of forecasting how much work could be pulled into a Sprint Backlog. Once actual work starts the original estimate usually doesn't apply. Re-estimating or splitting the story at the time where most of the work has been completed is not something I advocate.  I instead use it as an opportunity for discussion in the Retrospective about why the work was not completed, how could this situation be anticipated in the future so that new estimates take it into account. 

I see the Story Points very similar to an estimate provided by a contractor to remodel a bathroom. Based upon what is being asked, they will estimate the work that will have to be done. Once they start they will try to hold to that estimate but it may not be the case. They could find that the work was easier or that something they took into account on the estimate does not apply.  The opposite can happen as well when they find something unexpected that requires more work. At the end the bill may not match up to the estimate.  In this scenario would you expect the contractor to constantly revise the estimate or just communicate to you the situations that have occurred and their plan to mitigate it? 

Yes, my opinion is not always popular but I have seen it work. 

Velocity is a planning metric.   It seems Bartosz from your scenario that you are trying to "get credit" for points completed, which is a misuse of story points.   Story Points should not be looked at as a performance metric, lest they be gamed, and the Development Team's focus is then placed on story points and not delivering value.

As @Daniel mentioned, story points should be used by the PO and Development Team to judge what is acceptable to forecast for the upcoming sprint.   I promote the practice with my teams that, in support of this objective, all PBI's should contain a story point value that reflects the remaining effort to complete it.   And then, once the sprint begins, you should ignore the story points altogether, and focus solely on the items forecast, and whether you are on track to completing them by the end of the sprint.

Velocity is a planning metric.   It seems Bartosz from your scenario that you are trying to "get credit" for points completed

And that is exactly where a lot of things can go horribly wrong in the world of Scrum

Using the average velocity of several sprints, rather than a single sprint, will overcome the "up and down" of this scenario. Whether a PBI is marked as complete in Sprint 1 or 2 or 3, the average velocity between the three sprints should be the same, and can be used for planning.