Information in this page is outdated. Last update was made on 02 February 2016.

User Acceptance Criteria (UAC), ...Testing (UAT)

The goal of user acceptance criteria is to compile a set of statements that accurately identify what your customer does/does not want when commissioning your project. Establishing user acceptance criteria is an essential technique aimed at preventing project teams going of on a tangent and building something that your customer doesn’t actually want. Once done the end of the process, your team should have absolute clarity on what your customer does/does not want, and this will help you estimate/cost a project, and ensure it delivers the right set of functionality back to the customer.

User acceptance criteria are a collection simple, unambiguous statements that help clarify customer requirements in advance of project teams estimating work against them/actioning work. It helps to ensure that the project team delivers something in line with customers expectations, and helps to avoid expensive mistakes being made and remedied at a later stage.

User acceptance criteria can be used for all manner of projects, software, constructing a skyscraper, designing a vacuum cleaner, or even a kitchen tap (you might want to twist something right or left to increase/decrease the flow of water, or you might want to use another knob to change to mix of hot and cold water coming from a single tap)

In the case of software design, if we were to build a simple application for adding numbers, the acceptance criteria might read something along the lines of:

As a user I should be able to enter two numbers in seperate boxes on a single screen
As a user I should be able to click a button to perform a mathematical addition using the two numbers entered by that user
As a user, the result from the addition should be shown in a seperate box
As a user I should be able to click a button to reset the values in all three boxes to null at any point

The above acceptance criteria focuses on the actions and behaviour of a simple addition calculator as seen be an end user. There might be other acceptance criteria aimed at clarifying how sreen looks, whether its rendered using a web browser, or as a desktop application, on a particular platform. There is often more than one statement aimed at clarifying behaviour for a given requirement in a project. If you find there are too many, you may need to break the requirement down into smaller ones until you get to a point where it becomes easier to establish user acceptance criteria.

User acceptance criteria should be established before development takes place. Depending on the methodology you use (e.g. Agile: Scrum, Kanban; Waterfall) user acceptance criteria may be defined at the beginning of a project, at the beginning of an interation, or sometimes as and when a new requirement gets actioned.

The key thing is that before developers start developing, construction workers start constructing, robots start building, there is clarity over what exactly is being built, how it should behave in particular situations, how it looks, feels, costs, and takes to deliver. This makes it easier for developers and the project manager to estimate how long that work might take, and how much it will cost the customer, and also highlight anything that looks ambiguos or indeed impossible to achieve so this can be considered before proceeding with the work itself.

User acceptance critiera becomes the basis of “user acceptance testing”, or UAT, by the project beneficiary/sponsor.

Once your customer has agreed the user acceptance criteria, this user acceptance criteria can be placed under “change control”, that is to say that it cannot be changed without consent from all parties including the project team. So make sure that user acceptance criteria is reviewed and signed off by the customer, and that they understand that this is the specification the team are working to, and that it can’t be changed once signed off (actually it can, but only through a formal change control process which will add time/cost to the project).

If the business needs to change it, they have to issue a change request, which will be assessed in terms of any additional cost, impact to delivery of other parts of the project and timelines…and if the business is happy with this the project can be re-planned re-costed accordingly.

This means that the project team can effectively use the acceptance criteria as a specification to work from, in the knowledge that if all the acceptance criteria is met, the project will succeed and the customer will be happy and everyone can go grab a drink to celebrate.

But who does all this stuff, who figures out what the user acceptance criteria in the first place? That’s what Business Analysts are for!

So next time you’re running a project, and you want to make sure that whatever you’re doing has a good chance of meeting the requirements as set out by your customer, make sure you have a business analyst to help you tease out all the user acceptance criteria.

If you don’t have a BA, you may need to shoulder the responsibility of doing this yourself, so add this as a risk/issue, and increase the time/budget needed to cover yourself as its a non-trivial task, and one of the most important things to get right. By knowing the user acceptance criteria up front, you’ll know what your team needs to do in order to get signoff on your project being successful, way before you’ve actually started working on it.

Hope you’ve found this helpful! Feel free to click on sponsor links to show your appreciation, check out the polls and leave some comments.