Written Acceptance Criteria (AC) are one of the essential parts of the project documentation. They influence effective communication between the client and the development team, which is the key to success in the project.
So what are they, and what is the best process for creating AC?
Acceptance Criteria is a list of specific conditions and requirements necessary for defining a user story as complete from a business point of view. The criteria describe users’ needs and determine the system’, giving the development team a better understanding of what the product should look like.
The acceptance criteria determine the details of the user stories, so we should write separate criteria for each story. Remember that they should only describe what is to be done, the product’s features, and the functions it performs, without going into details about solutions or techniques. At this stage, it is vital to understand the goal that the client wants to achieve.
Creating the AC
Detailed acceptance criteria should be written before starting development work. Usually, it begins with the product owner presenting the idea and initial requirements. The next step is for the scrum team to clarify the specification and make the corrections so that both parties accept the agreed conditions. From now on, the story serves as a benchmark for the team to determine if the product is as expected.
The stories can be changed and updated as needed to ensure that all criteria are met, but this should take place before the development team accepts the story for implementation. If it is changed after the sprint has started, it could harm the schedule and workflow.
If the story has yet to be tested, it cannot be considered finished, so the QA specialist should also be involved in creating the acceptance criteria. Testers should check whether the issues affecting the quality of the product are noticed. They also need to pay attention to functional requirements - the way the product behaves or the reception of the application from the user's point of view. The product has to be intuitive, and the tester needs to check whether this intuitiveness will be included in the criteria. The non-functional requirements are just as important - features and limitations of the system, such as memory requirements, system performance, or security. It is also important to consider the different browsers, operating systems, and supported devices to ensure that the end product is what you expect.
Documenting the AC
What problems may we encounter if we don't keep the AC documented?
Incorrect estimates of the project completion
Developers can’t deduce how the functionality must work simply by looking at the designs and remembering all that was agreed upon in the project communication or the meetings. Furthermore, the estimation will be a massive problem since the scope is not defined. That leads to changing estimation while working on the task - it doesn't make sense to estimate the work.
Discrepancy between customer expectations and the manufactured product
Serious deficiencies and gaps in the application functionality will lead to many comments submitted by the client at the stage of project acceptance, which means the product still needs to be delivered in time. This generates more costs, and the client may become impatient.
The testing process takes more time
Creating test cases and scenarios without the detailed scope of the functionality will take a lot more time than usual. With no Acceptance Criteria, testers need to talk to the product owners or analysts to agree on the details, and they will only be able to test some things after the deadline.
Who should write the AC?
It's always recommended that the client designate a person responsible for documenting the acceptance criteria. It can be the client himself, but often it is a project manager or product owner - a person with extensive knowledge about the product. At every stage, cooperation between the client and the project team is essential - from creating criteria to implementing the project and controlling the implemented changes.
If the client transfers the responsibility of writing the acceptance criteria to the development team, which is not recommended, they should also get involved in the process. They certainly expect high quality, so they should do their best to clarify any doubts from the team. This will help them implement a product that corresponds to the vision and functionalities proposed by the client.
The team may need more detail to understand the customer’s vision, so the person representing the company should always be fully available to answer any questions and clarify any issues that may arise.
As a given problem may be perceived differently by each team, ensure that everyone (programmer, tester, analyst, UX-designer, or project manager) agrees with the product’s assumptions before starting development work. The more information you give to the development team, the better and cheaper the project will be.