How do you align user acceptance testing with agile development and continuous delivery?

I agree, but this may assume that you have all of this planned out in advance, which doesn't really align to the agile values. I would reframe this to a more incremental approach, where the UAT plan evolves over time and gets more robust as more functionality is developed and released. A team can start in an agile way of working and have some UAT happening within a week or two. And, just like the product and team processes evolve and continuously improve as the team works, so should UAT! UAT can start simple, just as the team may start simple with a small release. Then evolve the robustness as the team and product evolve as well, and continuously adjust and adapt as time goes on.

UAT that involves defining scope, documented tests, following scripts etc isn't UAT in my eyes. You're probably just using other people to increase formal test coverage or even worse duplicate it. What you want is to just give the system to real users and get ideas and feedback from them, by letting them use the system in ways they want, that you maybe didn't expect. If they don't know how to use the system, using documented tests isn't the way to show them. A useful help guide or documentation would surely be better and something you'd expect if a system isn't intuitive. Or even better, make the system intuitive.

Aligning User Acceptance Testing (UAT) with agile development and continuous delivery involves integrating UAT into the sprint process. I start by collaborating with stakeholders to define acceptance criteria early in the sprint, ensuring that UAT requirements are part of the user stories. During development, I encourage frequent feedback loops between testers and developers to address issues as they arise. UAT is conducted in parallel with development, allowing stakeholders to validate features continuously. Using automation tools helps streamline the testing process and integrate it into the CI/CD pipeline. Finally, I ensure that feedback from UAT is incorporated into subsequent sprints, promoting a culture of continuous improvement.

This means that UAT is continuous, as with most agile ways of working, continuous processes are the norm. The is fundamentally different for many organizations who are not used to continuous deployments. UAT, even in agile approaches, is not a phase! just like other types of QA work, discovery, and requirements; with agile these are continuous and integrated, rather than a phase.

To align UAT with agile development and continuous delivery, I make it a point to involve users early and often throughout the process. From the beginning, I bring users into the conversation, gathering their input on user stories and test scenarios to ensure we’re addressing real needs. As we move through development sprints, I invite them to participate in testing smaller features or increments of the product. By regularly involving users, we can catch potential issues early, adjust based on feedback, and ensure the final product meets their expectations.

Similar to my comment above, if you're automating UAT, in my eyes your not doing UAT. How is automating some checks going to show that users are happy with the system?

To adapt and improve UAT in an agile and continuous delivery environment, I focus on being flexible and learning from each iteration. After every sprint or release, I gather feedback from users and the team to see what worked well and where we can improve. Based on that feedback, I adjust test cases, refine our processes, and incorporate lessons learned into the next round of testing. By continuously tweaking and refining UAT based on real-time insights, we make the testing process more efficient and aligned with the evolving needs of both the product and its users.