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 once it is complete, these clients have no problem defining what’s wrong. Inaccurate or missing acceptance criteria can lead to low customer satisfaction levels, missed delivery dates, and development cost overruns. This is 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.
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 it 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.” It may also 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, make sure to take the time with clients in advance to determine what will define their projects as successful and complete in the end.