How to handle a story that will not be completed.

If the Product Owner is asserting that the work is not suitable for release, then the work shouldn't be integrated and released. It's important for the Product Owner to have that ability, to ensure that the product continues to add value. If the work won't meet the needs of the stakeholders or, even worse, would negatively impact the stakeholders, it is their decision that it should not be released.

I would consider this like any Product Backlog Item that is not Done at the end of the Sprint. It can go back into the Product Backlog, be appropriately ordered, and the team and work on refining it and ensuring that it's Done per the Definition of Done and also usable by stakeholders. It could come up again in the next Sprint, or it could be held for a future Sprint in the Product Backlog.

However, there is a good opportunity to have a discussion at the Sprint Retrospective.

Why did the Product Owner realize that the work that the Developers did was not quite what they want and how far did it the work that was done deviate from those expectations? Take a good look at how the team performs Product Backlog Refinement, Sprint Planning, and then executes on the Sprint - there are a lot of points for the different members of the team, whether it's among the Developers or between the Developers and the Product Owner, to come to an understanding of what the desired outcome of a Product Backlog Item is. It seems like the Product Owner didn't accomplish one of the things that they are accountable for - "creating and clearly communicating Product Backlog Items".

I'm not sure why the team "getting credit" for work is of concern here. The work is not usable by stakeholders. Unless this work not being completed prevented the team from achieving the Sprint Goal or even completing and releasing other work, the team did something of value. The Sprint Retrospective is a good opportunity to "get credit" for what was Done and realign with the external stakeholders. There could be some bigger issues if the failure to complete a single Product Backlog Item is of concern.

Another angle to this is to consider the Sprint Goal and how that guides decisions made by the Scrum Team. In this case, the Product Owner and Developers might collaborate and negotiate to find a creative solution that doesn't impact the Sprint Goal.

The Sprint Goal provides flexibility when the work isn't exactly what the Product Owner needs to maximize value, and may result in the Development Team changing the Sprint Backlog.

How do you mark a story that is complete but the PO decides is not quite what they want in production. 

As early as you can. In lean and agile practice, inspection and adaptation should occur as closely as possible to the time and place of work being carried out.

This gives the team the best opportunity to adjust their progress so the agreed Sprint Goal commitment is met, and to thereby receive credit where credit is due.

My concern with your question is why did the story not being quite right only surface at the Sprint Review?  Does your Scrum Team not communicate during the Sprint?  If I were on this team, I would make sure that this be the first topic discussed during the Retrospective. 

As for this statement

My concern is by canceling how does the team get credit for the work they did do?

I cringe when I see that kind of statement.  What credit is given?  Do they get a bonus if they finish their Sprint Backlog?  Do they get a ribbon or trophy? Is there a ceremony where they are recognized publicly at the end of each Sprint? I would bet that all of the members of the Scrum Team are being paid for the work that they do.  There is an expectation of the organization giving the paycheck that they will do work that is going to be beneficial to the company. In an agile environment, everyone should believe that no one will intentionally do something to cause harm.  So why do people need to get credit for completing a single story? Isn't the success of the products being built and the impact that has on the organization that is paying you enough recognition?  Companies typically reward people based on their contributions to the organization.  A single story is not going to make a difference.  Getting products that people want to use into the hands of those people is what makes a difference.  I'll get off my soapbox now.

Back to your question.  As a Scrum Master, I would want the team to understand how this happened.  There is apparently a disconnect between what the Product Owner felt the product should do and what the Developers understood it should do.  Since the Product Owner is responsible for making sure that the Product Backlog items are well understood by all, to me this seems to be more of an issue for the Product Owner to address going forward. The team needs to find ways of validating that the understanding is the same with everyone.  I have found that it is not enough to have the Product Owner explain the need and then ask "Does everyone understand?"  to which everyone else just nods or shakes their head.  As a Scrum Master you should help them to learn better techniques for sharing and confirming understanding of information. Have Developers explain their understanding of the problem to be solved to the Product Owner.  Have the Product Owner and Developers explain the problem to be solved to you as the Scrum Master. Bring them together to actually discuss the issues and not so that one person can explain them.

Credit ought to be given for eliminating waste. If it turns out that a story is not required, it is best to identify and act upon that as soon as possible, to minimize the amount of waste.

Even if this is only realized after a significant amount of work was done, once it becomes apparent that doing the remainder of that work is a poor investment, people should be courageous and respectful enough to acknowledge the lessons learned and change direction accordingly.

Excellent points of introspection provided by all! I love the way we slice and dice the problem to get to the root of it; that's why this is one of my most loved and respected Scrum forums!

Having said that, I probably can see from where @Lisette L. Fernandez is coming from. In most of the organizations that I've observed, the senior management still doesn't understand Lean/ Agile/ Scrum, least to expect the finer concepts of these. They still measure success via 'Story Points delivered versus Story Points committed'.

In this environment, when management reports get collated at a program level (collection of several teams), comparisons are bound to happen between teams that have 'delivered' consistently that they have committed for, even if that means they just split uncompleted Stories to get the credit of the 'partial' work done. However pathetic this may sound, this is the reality in which we need to operate. 

My only opinion (alongwith the brilliant opinions of the other members in this thread) would be to consistently and relentlessly work on facilitating the adoption of Scrum values and principles within the organization, however long that may take. I too work on my due share on this; haven't got much success so far, but that won't necessarily deter me in continuing to do what Scrum encourages us to do:

• Leading, training, and coaching the organization in its Scrum adoption;
• Planning and advising Scrum implementations within the organization;
• Helping employees and stakeholders understand and enact an empirical approach for complex work;