Beware the dangers of the UAT environment

In an Agile world delivery should be just like voting in Chicago, early and often.
As per The Principles behind the Agile Manifesto, the first one says "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." (emphasis mine)

A UAT environment (User Acceptance Testing) where users test the software, log bugs, wait for updates determine if they will accept the release into production, where someone outside of the Scrum Team determines when the testing is complete, prevents us from delivering the product to the end users.

There are a number of reason that I have seen for why UAT environments are created

1. We need to verify that the data is being edited correctly by a tool

2. We need to make sure that this new functionality will satisfy user's needs
3. It isn't really UAT, it is just misnamed

Let's address the third one first. If this "UAT" environment is where the product is staged so that it can be shown to the stakeholder during Sprint Review, then we should probably rename the environment to reflect that usage. That should be easy to rectify outside of the fact that naming is hard as can be seen by the number of posts on naming if you follow that link.

Why are the first two bad? They take the acceptance criteria and move their understanding and completion out of the Scrum Team's hands. A story is complete when, and only when, the Scrum team has determined that they have satisfied the Acceptance Criteria and Definition of Done. No one outside of the Scrum team can make that decision, if that is needed it means that the Acceptance Criteria is not crisp enough and that issue is what needs to be corrected. A good Acceptance Criteria is a testable assertion, a statement that is clear to all if it is met or not, preferably one that can be verified with an automated test.

Some examples of good Acceptance Criteria:

• When the customer completes the ATM Withdrawal transaction and they have enough money in their account and there is enough cash in the ATM, then they are given the money. 
• Pressing the print button will cause the form to print out exactly as it is shown on screen.

Some examples of bad Acceptance Criteria:

• When the user presses that button they see the result
• The users will be able to manage all aspects of the process upon completion

Note, these last two are just a bit vague. We do not need to be, and should not be, writing Acceptance Criteria using lawyer speak, but there does not be a very clear and crisp understanding of when the Scrum Team's work on the story is complete. The Acceptance Criteria can be viewed as a pseudo-contractual agreement between the Scrum Team and the stakeholder that they shook hands on.

To be able to satisfy the customer through early and continuous delivery we must be able to get product into production. UAT hampers that ability. It is our job to educate stakeholders and help them understand that it is in all our best interests to get the product in the hands of the users as quickly as possible so that we can get direct feedback from the users. This will allow us to, as the ScrumGuide says, "deliver products of the highest possible value". 

Hopefully this has highlighted why we need to avoid UAT environments. While Joan Jett may not give a damn about her bad reputation, I would rather not tarnish mine delaying getting product into user's hands due to UAT.

Stay Agile.