There has been a lot of talk in the agile development community about acceptance criteria.  Most teams realize that having clearly defined acceptance criteria before initiating development makes development a lot easier. And it does! I’m a big fan of acceptance criteria. In this article, I will describe how business analysts can use acceptance criteria to create better requirements. Acceptance criteria work for both agile user stories and for plan-driven functional requirements. Please don’t believe that they are only for agile development.

Accurately defining a client’s acceptance criteria is one of the most important elements of a successful development project. Microsoft Press defines Acceptance Criteria as “conditions that a software product must satisfy to be accepted by a user, customer or other stakeholder.” Google defines it as “pre-established standards or requirements a product or project must meet.” No matter how they are defined, clearly delineated acceptance criteria are critical to project success.

Clients often have a hard time defining acceptance criteria at the start of a project. Conversely, once the solution is delivered, clients seem to have no problem defining what is missing or wrong. Inaccurate or missing acceptance criteria can lead to low customer satisfaction levels, missed delivery dates, and development cost overruns. That’s why it’s absolutely critical to accurately define criteria before any development work begins.

Projects succeed or fail based on the ability of the team to meet their clients’ documented and perceived acceptance criteria. Including acceptance criteria as part of the requirements documentation greatly enhances the likelihood of a successful project.  When you clearly define acceptance criteria up front, you avoid surprises at the end of a project and ensure a higher level of customer satisfaction. So, take the time with a client to determine what will define their project as successful and complete, and track and report progress against those criteria.

Acceptance criteria should be written from the perspective of the end-user or customer. That may seems obvious since user stories are written from the perspective of the end-user or customer. However, even for the best-written stories, acceptance criteria are where the development and testing perspective seems to creep in.

Acceptance criteria should be written before development begins. Many teams leave development of acceptance criteria to QA.  This is a bad practice and often leads to verifying that functionality built works rather than verifying that the functionality meets user needs and expectations. If you write and review acceptance criteria before implementation begins, it is more likely to capture the user intent rather than the development reality. Good acceptance criteria help developers build the right solution. Acceptance criteria are best delineated by business analysts during requirements development.

Guidelines for writing good acceptance criteria include:

• Usability – Be sure to include measures of usability in your acceptance criteria. In other words, you need to identify how to answer the question, is it easy to use? Don’t’ just write, “must be easy to use.” How are you going to measure this? For any given feature, we may measure ease-of-use by looking at the rate of successful use, setting an acceptable threshold. Or we might set a threshold for time to completion. The key is to identify the right measure or measures and to make sure each measure is readily quantifiable.
• Functional Acceptance Criteria – Identify specific user tasks, business processes or functions that must be in place at the end of the project. A functional requirement might be “When the user clicks on the Size drop down list, a list of available sizes will be displayed.” 
• Error Handling – Acceptance criteria should also include error handling. What data are you expecting that might not be there? How will you handle each instance of missing data? What happens if someone does something out of order? Or if they stop halfway through and then come back later? What happens if someone doesn’t have the data you are asking for? Can they move on or are they stuck? Enumerating error cases is a great opportunity to surface all of your assumptions, particularly around data needs, and how to resolve them if they are wrong.
• Performance – Acceptance criteria should also define and include performance criteria. Performance testing is from the perspective of an individual user. Does the page load quickly? Is the UI responsive? Do I have to wait for ads to load before I can view content?  In this new world of cloud and hosted computing, it can be difficult to quantify performance.  So performance is usually measured as response time. Expected performance should be clearly spelled out as a range such as “1-2 seconds for a screen to refresh.”  And it may make sense to separate out and define performance for specific parts of the solution. 
• Stress Tests – Stress tests measure what happens when you are inundated with lots of users, transactions, or queries. What happens when the system is under stress? Acceptance criteria should define acceptable thresholds for stress testing.

Acceptance criteria define the boundaries of a user story, and are used to confirm when a story is completed and working as intended. Let’s look at an example of some acceptance criteria for a simple user story.

User Story: As a customer, I want to be able to order and pay for the book via a secure-web based form.

For the above example, the acceptance criteria could include:

• All mandatory fields must be completed before a customer can submit a form.
• Information from the form is stored in the customer orders database.
• Payment can be made via credit card (Amex, Master Card, and Visa).
• The system shall accurately calculate and apply sales tax.
• The system shall accurately calculate and apply shipping charges.
• The customer shall be able to verify the accuracy of the order.
• An acknowledgment email is sent to the customer submitting the form.
• Protection against spam is working.

As you can see, acceptance criteria are written in simple language, just like the user story. When the development team has finished working on the user story, they demonstrate the functionality to the product owner, showing how each criterion is satisfied. Including acceptance criteria as part of your user stories has several benefits:

• It requires the team to think through how a feature or piece of functionality will work from the user’s perspective.
• It remove ambiguity from requirements.
• It forms the tests that will confirm that a feature or piece of functionality is working and complete.

[cta id=”7441″]