The Agile Manifesto contains no mention of user acceptance testing (UAT). With short iterations, developers, testers and business analysts are working together on a daily basis churning out working product. With short iterations in Agile, sometimes Acceptance Testing for each iteration can be mistaken for UAT. Yet, UAT is best done by real business users or end users who have the knowledge to check the functionality not only for delivery as per the defined business requirements, but also to make sure it can support them in their daily tasks on the job.Usually, business users take time out from their regular jobs to conduct user acceptance testing. These users support the testing effort and return to their job when the UAT is completed. The problem is that not everyone is a good tester. Business users without knowledge in testing often lack an eye for recognizing patterns and may be focused on using the application only for their particular task. They may also not have a curious mindset to execute negative tests, things that the system should not do. Additionally, UAT usually happens at the end of the delivery cycle when it may be too late to correct any significant problems. That's the last thing you want in Agile. In this webinar, Philip Lew discusses how Agile ideals fall short when it comes to UAT and how to adapt Agile as well as traditional views on what UAT is in order to reach the overall quality objective of meeting business requirements through quality software. Listen in as Phil breaks analyzes and breaks down the problems and then discusses strategies for implementing UAT through methods that can be adapted to each organization's flavor of Agile.