Who's owns UAT in Agile, regardless if it's Scrum, Kanban, etc...

Is UAT work that must done in order to create a release-quality increment?

Is an increment considered releasable before it has gone to UAT?

If so, any work that results from UAT should probably be handled as new Product Backlog items to be prioritized by the Product Owner.

In this case, there is little within the Scrum Guide to suggest who would conduct UAT, but the Product Owner should at least be interested in the outcome.

If an increment is not releasable without passing UAT, then this should probably be included in the Definition of "Done".

According to the Scrum Guide:

A "Done" increment is required at the Sprint Review. Only members of the Development Team create the Increment.

In such a case, a logical default would be for the Development Team to carry out UAT. This could involve the Development Team expanding to include individuals with the skills to do this. It could even be the Product Owner is simultaneously a member of the Development Team.

It might be that the Development Team can benefit from certain agreements or mechanisms in place within the organization, such that there is someone able and willing to organize UAT. This could be the Product Owner or anyone else.

But because the ability to produce a "Done" increment would be so tightly coupled to this process, a Development Team should certainly take an interest in making sure UAT takes place at the right time and in the right way to maximize what they are able to achieve.

I'd agree with Ian Mitchell and Simon Mayer - your first step should be to define your User Acceptance Testing with respect to your Definition of Done. Either UAT is something that is required for the Increment to be Done or is something that happens after your Development Team produces a Done Increment. This will define who is involved with or responsible for the UAT activities.

Personally, coming from industries where UAT has very specific meanings and implications, I tend to view it as something that is done outside of not only the Development Team, but the entire development organization, unless the development organization is also a user of the system. The entire purpose of UAT is for representatives of users to confirm that the built system is fit for their intended use, which requires intimate knowledge of their processes, workflows, and how the built system fits into that process or workflow. Although I would expect the Product Owner to have this information and work to convey it to the Development Team, a UAT would reveal misunderstandings or issues that slipped through the PO and Dev Team.

Depending on exactly what your system is and who the users are, I could conceivably see a lightweight UAT being conducted as part of your Sprint Review. This would definitely depend on the size, scope, and criticality of the changes, as even a 4 hour Sprint Review may not be enough time to perform a complete UAT for complex changes or a large number of changes in a complex system. Alternatively, however, you may decide on the scope and goals of a Sprint based on the user's ability to accept the changes if you take this path. This will require user stakeholder involvement in the Sprint Review event, which is a good thing anyway if you can get it.

At the end of the day, Scrum doesn't explicitly assign UAT roles and responsibilities to anyone. There are a number of good ways to insert it into the framework and elements such as the Definition of Done and Sprint Review can help you fit it into the way the teams work.

Thanks for taking the time to respond.

An increment is considered releasable once it has gone through QA and UAT. And it is part of the DoD.

I would have thought that this would fall solely on the PO, since that role interfaces with the users/stakeholders, and they are the ones that use the tool/solution. Dev does not use the tool, so can't see how Dev can perform UAT.

thanks again,

Whoever the user is or is represented by, should participate in UAT regardless of title and role.

I would want anyone on my team to value this feedback higher because this is a reflection of their work. It's why they are attempting to BE Agile. 

I use the analogy of a desk sold by IKEA or some similar store. My team made the desk and we want IKEA to display it so people will imaging themselves using it after they see it on display.

We know the size/dimensions preferred and basic needs of the desk. We even made some user documentation in the form of building instructions.

In UAT, we want to know if the instructions make sense but you don't have build the desk. Our team tested that already against the documentation.

What we need you to do is just ... use the desk.

Grab your preferred chair, does it sit at a reasonable height? How's the leg room? Did you put your gaming PC tower on top or below? Are you using the desk as a crafting table?

My point is, it doesn't matter who performs the UAT as long as the UAT has appropriate coverage and someone is there to answer questions. Might also be good to have someone there to take notes too.

We want to make sure that the UAT participant is not just a new user too. Bring in someone who is considering replacing their current desk with this one. Does your day-day processes fit in? By using this desk, are you prevented from doing anything you normally do today?

To tie this back to Agile ... we attempt to be Agile so that we are providing the customer what they need, early and often. It's our responsibility to ensure we're giving that value to our customers and not instead only focusing on the work and it's progress and it's rate of closure and the output. We can already do all that without needing to be Agile.