UAT in an Agile Environment

In a previous post, I highlighted the importance of product owners being involved in testing. Whether they realize it or not, they’re already playing a role. That brings us to a natural next question: where does User Acceptance Testing (UAT) fit in Agile?

Ask around, and you’ll get plenty of opinions. Some argue that UAT belongs right in the thick of Agile teams, while others contend that it’s unnecessary or redundant. Here’s how I break it down:

When users are embedded in the team, it makes perfect sense for them to get hands-on with new features early. Their feedback, delivered sooner rather than later, helps shape the product and catch issues before they grow.

From a static testing perspective, it’s a definite yes. Early reviews of user stories, clarifying vague requirements, and ongoing feedback loops all count as forms of UAT—even if there’s no working software yet. This early involvement is crucial for refining what’s needed and ensuring the team is building the right thing.

On the flip side, sometimes it’s just not practical. Maybe the only chance for feedback is during the end-of-sprint demo. Or maybe users are tied up planning for future sprints and can’t get involved until later.

In some cases, the work may be purely back-end or architectural, with nothing visible to users for testing. Here, static reviews might still happen, but dynamic user testing just doesn’t fit.

And let’s be honest: running a full-blown UAT sprint after everything’s built? That’s more waterfall than agile. At that point, you’re basically running a beta test.

Whether UAT happens during the sprint, at the demo, or in a dedicated cycle, it all depends on the team’s planning, comfort level, and maturity. There’s no single right answer—just what works for your team and project.

Let’s talk about how to tailor your testing practices for real-world results. Reach out at jberriault@berriaultandassociates.com and let’s make Agile work for you: UAT and all.