Story points and remaining

Velocity is the rate at which work is Done, not part Done. Any Product Backlog item which has not been completed cannot contribute to velocity. It is simply re-estimated on the Product Backlog so the backlog tells the truth about how much work is currently believed to remain. If that item still tells the truth about what is thought to be valuable, it is not rewritten to tell something else.

Scrum is about innovation and learning to build the right thing at the right time. We are not story point accountants.

Hello Ian, thanks for your reply, but I don't really get the answer. Could you please give me an example? Thanks!

Ian explained it very nicely.
I try to put it into an example:
You said that at the end of the sprint there was 3+5=8 story points uncompleted. Uncompleted Stories are moved back to the product backlog and are not contributing to the velocity. So total current velocity for your ended sprint is
30-8=22.

In case the same stories are pulled into next sprint then you need to re-estimate those beforehand.
But instead of overcomplicating calculations of the velocity, I suggest you to inspect what was the reason why you were not able to finish planned items in your sprint and adapt. Were the team too optimistic? Stories too big? Were Stories poorly described and therefor estimations were wrong? etc...

Begin with the end in Mind !.You are looking for ways for next Sprint planning, But will the 'half Done' backlog item meets the DoD if you split it ? if not, splitting user stories are going to help only in the bookkeeping and not to deliver value. You mentioned the team should retrospect on this point, but i think by having the option to split the 'not Done' stories(even if the 'half done' work can't be released), Wouldn't it hamper the sense of accountability in the team indirectly ?

Hi @Marko Kuusk, I see your point(s). My only question is: considering that part of the work for the non-delivered user stories is already done, when re-estimating the user stories before putting them in the next sprint, how the partial work impact the estimation?

Let's come back to my previous example: let's say that the user story of 8 sp was correctly estimated but not completed because the dev has to take 2 days off at the last minute. When resizing this user story for the next sprint, shall the team size only the work still to do? Or shall the 8 sp be kept entirely since it was the correct sizing?

I'm going to be a bit blunt and I apologize upfront if I offend anyone.  

Why are you asking us this question?  We have nothing invested in the decision.  You should be asking the team faced with the situation to decide on how they want to handle it.  They are the ones being judged by their ability to make up a guess based upon information they have and then delivering the item within some imaginary limitation of "points". Let them decide how they want to handle it and game the system by which they are being judged.

Story points do not reflect work. They do not reflect delivered value. They reflect a general sense of common understanding.  They allow a group of individuals to show solidarity on a described problem. There should be no other use for them.  Teams should be evaluated on their ability to deliver things that the stakeholders want to use and say are valuable. A single Product Backlog Item that is refined into a size that can be confidently completed in a single Sprint might not deliver the total value. It could require multiple items to do that.  That is why a Sprint Goal is created. It shows the reason that the Sprint is important and what the value is that needs to be delivered.  That is your real measure of a team's worth. There is a TV show called "Who's line is is anyway?".  

"Welcome to Whose Line Is It Anyway? The show where everything is made up and the points don't matter." 

I feel that line is appropriate for software development using story points.  Everything done in a Sprint is made up at the time it is done. Developers make up the code as they write it with a sole purpose.  The points that are used do not matter once a Sprint starts. And the never really had any value related to work. 

Hi @Marko Kuusk, I see your point(s). My only question is: considering that part of the work for the non-delivered user stories is already done, when re-estimating the user stories before putting them in the next sprint, how the partial work impact the estimation?

You are considering only one scenario here. There is also a scenario where the team recognize more work/complexity and realize that the story was underestimated. Re-estimating is the best way which works in both the scenarios. It is important to check in the retrospective why we could not foresee the additional work or why we could not complete the work which which was committed.

Focusing on value delivery is what is critical as most people have commented here. 

considering that part of the work for the non-delivered user stories is already done, when re-estimating the user stories before putting them in the next sprint, how the partial work impact the estimation?

There is nothing done about an item until it is actually done. There is only work started but not finished. If something was actually “done”, then that backlog item could be split and the done part delivered in order to gain value from it. If you have nothing that can be delivered yet, there is nothing done about it.

Let’s say that the user story of 8 sp was correctly estimated but not completed because the dev has to take 2 days off at the last minute

You have no idea if this work would have been completed or not. Even if the dev didn’t take those 2 days off, they still could have run into issues and not brought this item to completion - are you familiar with the 90% syndrome?

Given the above, you have no idea if it was the “correct” sizing, and the “correct” sizing isn’t really a goal to work towards (this can be a wasteful exercise).

There is nothing golden or magical about a first guess/estimate and there is no need to get hung up on it.

Given this item was not completed, it goes back into the product backlog as others have mentioned. It is sized based on the work associated to it so the team understands its potential impact to capacity in the next Sprint. There may be more or less work remaining as Anand mentioned. I don’t like to consider this as “re-sizing”, only sizing. The backlog item as evolved. We are working empirically and making decisions based on what learned right? Size it like you would size any other backlog item using the most current information.

Side note: If the backlog item the dev was working on was needed in or to achieve the Sprint Goal, then the team could have taken on this work. No one person owns any single backlog item.

Thanks everybody for your replies.

@Ryan Kent your reply was enlightening, thanks a lot.