Acceptance criteria refers to a set of requirements needed to be met before a product or software is accepted by the user or stakeholders. It’s sometimes referred to as the definition of ‘done’, as the conditions must be met for the user story to be considered complete. We take a look into reasons behind creating acceptance criteria and best practices.
What is acceptance criteria?
Acceptance criteria refers to the conditions that a product needs to meet to be accepted by the end-user. These will be unique to products you work on and will define expectations of the software for an end-user. When acceptance criteria are well-written, it ensures the final stage of a project runs smoothly. It also ensures that everyone is satisfied with the software. A successful project requires developers to meet customer expectations.
Unfortunately, sometimes client’s requests and requirements are vague at the start of the project. This is why acceptance criteria are used to ensure all are on the same page. Acceptance criteria and user stories work as a way to document requests. The criteria help to give teams measurable and specific targets so they know when the project is complete.
However, for acceptance criteria to be effective, it needs to be written so all can understand it. It will contain information unique to the document and should not merely be a copy of initial project requirements.
When to begin creating acceptance criteria
Most companies opt to write acceptance criteria at the same time as user story ideas are being deliberated. However, this can also be done later on in the process, if needed. Further down the line, additional acceptance criteria can be added to accommodate challenges or adjustments.
While there’s no set time you must write these criteria, it’s important to make sure they are confirmed before your team starts work. Upon completion of a user story, the development team will show the client how it meets the acceptance criteria. This limits any confusion or communication issues and clearly demonstrates the completion of the user story. For developers, this also works to their advantage by minimising additional work.
Who should write it
Most commonly, the product manager or owner will be the one to write the acceptance criteria. However, there’s no reason this task couldn’t be assigned to almost anyone on a cross-functional team. It’s generally recommended that your development and QA team are involved in the process.
They can provide greater insight into the vision and strategy of the product. They’ll also be able to share any missing parts or dependencies that may not be clear. By involving extra team members in discussing and writing your acceptance criteria, you’ll create effective and clear guidelines for everyon.
Creating effective acceptance criteria
Acceptance criteria are only useful to everyone if they are written clearly and effectively. Firstly, you need to ensure all acceptance criteria that are written can be easily tested. They should be clearly written to avoid any ambiguity, and the requirements should be met using a simple yes or no response.
Avoid writing an essay for each point, and instead, try to be as concise as possible. It needs to be understood by both your team and client, and you’ll want to take the time before getting started to clear up any confusion beforehand.
Make sure it comes from the user’s perspective and put yourself in the shoes of a user. Write from their point of view instead of writing technical points that developers understand. Good acceptance criteria will separate both functional and non-functional requirements.
Criteria can then be categorised between these two areas. Functional requirements focus on the technical features of a project. Non-functional requirements concentrate on appearance and non-practical elements.
To help measure expected performance with your acceptance criteria, ensure you state a time or desired result. Don’t use vague terms that will be difficult to judge when confirming your acceptance criteria have been met. Finally, ensure any defects are noted within the acceptance criteria and understand how they should be dealt with.
Writing and formatting
Now that you know how to create effective acceptance criteria, it’s essential to understand how to format it. Follow a similar layout to user stories, usually based around the given/when/then style. Alternatively, you may prefer to offer it in the form of a checklist.
You need to use ‘pass’ and ‘fail’ options or ‘yes’ and ‘no’ statements to ensure the requirements are fully met. While these two formats are the most common option, it can be in any format as long as everyone understands it. If your team can work from these guidelines, you’ve succeeded in creating effective and well-written acceptance criteria.
Acceptance criteria can help to solve and avoid many issues within your development process. Many companies still fail to take the time to write effective acceptance criteria. This can be disastrous when it comes to sharing your work and user stories with the client. Document your acceptance criteria clearly, and write them from an end-user’s perspective.
By following our tips, you will avoid ambiguity and ensure that everyone knows what they are expected to create. The format you use for writing acceptance criteria is not as important as the writing itself. As long as everyone understands the work, you’ll create a product that your client and stakeholders will approve without delays. Call today to find out how we could use acceptance criteria, whilst developing your software project.
