The Importance of Clearly Defined Acceptance Criteria

June 16, 2010

Technology

Bob Cody

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 you define it, clear Acceptance Criteria are critical to the success of a project.

Clients often have a hard time defining Acceptance Criteria before the start of a project. But at the close of a project, these clients have no problem defining what’s 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 so critical to accurately define them before any work begins.

Software development projects will succeed or fail based on your ability to meet your clients’ documented and perceived Acceptance Criteria. They should always be included as part of the requirements documentation, so be sure to write them down early and refer to them often. By taking the time up front to do this, you accomplish two key project and customer service tasks.

1. You set the client’s expectation level and lay the groundwork for their perception of the completed product.

2. You take an important step toward protecting your company and your client.

Acceptance Criteria should not be a re-hash of the requirements document and should include:

Functional & Non-Functional 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.” A non-functional requirement could be “The company logo will appear in the left hand corner at the top of each page.”

Open Issues/Defects: Define what is acceptable for open defects. For example “Critical and high priority issues must be corrected, medium priority issues will be reviewed, and low priority issues will be prioritized for the next release.” If your schedule includes repeated iterations of the testing cycle, high priority issues will be addressed early on in the project. Critical issues should occur infrequently.

Performance: In this new world of hosted solutions, SaaS / Cloud Computing, and web services, it can be difficult to quantify performance. So performance is usually measured as a response time. Expected performance should be clearly spelled out as a range such as “1-2 seconds for a screen refresh.” And it may make sense to separate out and define performance for specific parts of the solution. We recommend that a project proposal include a separate post production phase to address specific performance issues.

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.

Bob Cody

Director, Technology Consulting