Given that the User Story we are carrying over is partially complete, how do we estimate for it correctly in the next Sprint Planning session?
I don't think options A through C are good, mainly because what (I think) should be most important regarding a team's velocity is it's average velocity and not whether the velocity of any given sprint went up or down.
When a user story is defined, it should have acceptance criteria. If anything in the acceptance criteria is not done, then the team simply does not earn any of the points. If the story is done-done (i.e. coded, tested, and accepted by the P.O.) then the team gets all the points.
This works well when the team is focused on its average velocity rather than on a given sprint's velocity.
Like M. Cohn in his book, I tend to have a preference for an all-or-nothing scenario. After all, trying to estimate whether you've completed 5 points out of an 8 point story, or maybe just 6 or 7 is just going to end up being another guessing game... and don't forget that you already got the initial estimate way off. It's probably better to just go with the simplest method and when get all the points after it has really been completed.
Quoting M. Cohn from his book¹ (my emphasis):
I’m generally in favor of an all-or-nothing stance toward counting velocity: if a story is done (coded, tested, and accepted by the product owner), the team earns all the points, but if anything on the story isn’t done, they earn nothing. At the end of an iteration, this is the easiest case to assess: If everything is done, they get all the points; if anything is missing, they get no points. If the team is likely to take on the remaining portion of the story in the next iteration, this works well. Their velocity in the first iteration is a bit lower than expected because they got no credit for partially completing a story. In the second iteration, however, their velocity will be higher than expected because they’ll get all of the points, even though some work had been completed prior to the start of the iteration. This works well as long as everyone remembers that we’re mostly interested in the team’s average velocity over time, not in whether velocity jumped up or down in a given iteration.
¹ Agile Estimation and Planning, Re-Estimating Partially Completed Stories, p.66
My team had previously attempted to assign partial points, despite some objections, and I don't think it worked well at all. (We don't do it anymore...go figure) This is especially the case because stories are supposed to get estimated as a team, yet if only one person is working on it, it'll be more difficult for the team to know how much an individual has actually completed. Agile is more interested in a team's average velocity rather than on how "nice" a particular sprint looks.
That being said, the author does mention that assigning partial points can be considered if the team is unlikely to tackle the remaining work in the next iteration. In this case, the team would estimate the work that remains and break it down into new user stories with whatever size they feel they should have. As the author mentions²:
The combined estimates would not need to equal the original estimate...
² Ditto, p.66
The better recommendation for the team is to break stories down to a sufficiently small size to avoid this kind of problem³:
However, the two best solutions to allocating points for incomplete stories are not to have any incomplete stories and to use sufficiently small stories that partial credit isn’t an issue.
³ Ditto, p.67
Hope this helps.