When does UAT happen?

What are your thoughts about proving work fit for release as early and as often as possible?

I'm going to start by addressing a pet peeve of mine.  There is no such thing as SCRUM.  It isn't an acronym, product name or company name.  Scrum is a framework that can be used to improve the agility of an organization.  Ok, now to your question.

One thing you need to understand is that as far as Scrum is considered there is no such thing as UAT.  Nor does it consider code review, build passing, test plan creation, deployment, or product documentation creation. Not because they aren't necessary activities but because they are process steps and Scrum is process agnostic. The reason you have found so many different answers is because there are a lot of different answers justified on what is right for the organization providing that answer. In some cases UAT is not necessary or even considered an activity by some organizations.  I have not worked for an organization that used UAT since 2008. 

By answering @Ian Mitchell's question you will arrive at the answer to your own question. But that answer should be based on the information you have available right now for the organization for which you work.  Ask that question again at some point in the future and you may arrive at a different answer, even if you are working for the same organization. 

You didn't ask for this but I'm going to give you some advice.  Be careful what sources of information you consider to be "correct".  There are a lot of websites, blogs, books that say they will tell you exactly how to do Scrum.  The only true source for what Scrum entails is the Scrum Guide provided freely at https://scrumguides.org/.  Study the guide and use it as a measuring stick for your studies. If you read something that says anything that doesn't align with the principles of the Scrum Guide, you should really question the validity. There are a lot of posts in this forum where people ask questions they have encountered in assessments or provide statements that they have found on "reputable" sites that do not align with the Scrum Guide.  

Good luck with your studies. 

In addition to Ian Mitchell's and Daniel Wilhite's comment, I'd point out that UAT means different things to different people. For me, user acceptance testing is a formal step that is required before functionality can be deployed (or enabled, if using feature flags/toggles) to a production environment in order to allow end users to ensure that the system remains in a validated state. For others, UAT could simply mean a user (or appropriate user representative) reviewing a piece of functionality and determining that it does meet their needs.

You should figure out exactly what "UAT" means to you, how that definition of UAT is best incorporated into your process, and (most importantly) how you can be responsive to user feedback and get feedback as quickly as possible to confirm that the work that you are doing is correct.

I really like what Daniel said! 

My advice for you is to question the value or need of a UAT. I think by doing so you would find all three of your examples being true. 

There is no process in Scrum to include UAT because the needs of a UAT should be received through the various activities of your Scrum team. The fact that one is needed implies that there isn't great amount of trust that the Scrum Team understands the expectations of the customer needs. So the UAT is opportunity for those folks to approve what is built meets their needs and expectations.

Perhaps start there. Determine if the needs and expectations are captured well in the Scrum Team.

• To be a part of DoD, "everyone must know what Done means". Often you will need to ensure how the story is written truly keeps the customer PoV in mind. You Product Owner is the Customer Proxy. They should be able to determine if the completion of the story meets the needs well or not. So an example DoD would be that the PO approves every story before it's called Done.
  
   
• For it to be a part of the Sprint also applies a little of what I just said. How well the story keeps the Customer PoV in consideration will reduce the gaps between them and the team. That should be achieved anytime during the Sprint as Stories are ready to be closed.
  
   
• For the Sprint Review, you would want someone in the current UAT party to attend Sprint Review but demo the Sprint Goal/Objective relating to them and not the individual stories, unless it's actually needed of course. 

If you're going to make a change, communicate the change to the customers with the PO in the room.

Build the trust through communication and reinforce it by achieving the expectations. Often by doing so, the customers will suggest changes because let's face, they don't know what they want until they see it anyways. The PO will be able to speak on when they can make them or if they will even make them.

Hope that helps you!

Scrum requires the Scrum Team to craft a potentially releasable increment "at latest" at the end of each Sprint.

Can you call the product increment "potentially releasable" without passing User Acceptance Tests?

Can you call the product increment "potentially releasable" without passing User Acceptance Tests?

Or, can you get feedback sooner, from the Product Owner, during the sprint, to ensure you're on the right track without introducing another process or gate for "user acceptance testing"?