There’s no question that effective communication between a client and the development team is essential to create a successful IT project. Here’s where acceptance criteria can help. What are acceptance criteria, and what is their main purpose?
The success of any project lies in the development team’s ability to meet its client’s needs. Well-written acceptance criteria help avoid misunderstandings and get the job done on time.
Table of Contents
What are the acceptance criteria?
Acceptance criteria (AC) used in agile methodologies are a list of specific conditions and requirements to mark a user story as complete. The criteria describe the users’ needs and determine the exact system functionalities so that the development team better understands what the final product should look like.
The AC defines the details of user stories. It is good practice to write different AC for each story. Note that acceptance criteria should only describe the minimum level of functionality and features for the product. They should not include technical details because they’re about the client’s intent, not the solution itself.
What distinguishes effective acceptance criteria?
1. You can test them.
Acceptance criteria help formulate a definition of completion for engineers, so they must be easy to test. In turn, the results of these tests must leave no room for interpretation. The results should be precise on a yes/no or pass/fail basis.
2. They are clear and concise.
It is not the place to write down extensive documentation. Criteria should be as simple and transparent as possible.
3. Every team member can understand them.
Criteria should be clear enough for all team members to understand. If something isn’t undeniable, it’s better to take the time to seek additional information and make corrections.
4. Take care of the user’s perspective.
Acceptance criteria are always closely related to looking at the problem from the customer’s point of view. They should be written to understand the audience’s needs and actions.
Acceptance criteria from the team’s perspective
The criteria should be introduced before developing any software. The project starts with a product owner presenting the idea and initial requirements to the team. Next, the team clarifies the details included in the specifications and makes the necessary corrections, and both parties agree on the conditions set. Then the team can use a user story as a reference to assess whether the product is completed as desired.
If needed, stories can be changed and updated to reflect all the criteria, but only before the user story is marked as done. It shouldn’t be changed once a sprint starts because doing so will have a negative impact on timelines and estimates.
The contribution of QA to acceptance criteria
A user story can’t be considered done unless it has been tested, so a QA specialist should verify whether all requirements and development goals can be met based on the AC. However, QA is much more than just writing test cases and reporting bugs to the team.
QA is involved in the project from the very beginning and is part of the conversation. The QA specialist’s role is to inform the team about issues that may affect product quality or when something doesn’t seem right. These issues could be cross-browser problems or RWD challenges, to name a few. The QA specialist should also pay attention to both functional (ways a product must behave) and nonfunctional (system’s operation capabilities) requirements, as well as different browsers, operating systems, and supported devices to make sure that everything will go as planned.
Another thing the QA specialist is responsible for is making estimations and capturing complex and negative test-case scenarios before the product goes to end-users.
What about the client?
We recommend having a person responsible for defining the criteria. Based on our experience, it’s better when there’s someone on the client’s side who provides the development team with the criteria that should be met. If the client is not familiar with how to write criteria, then we recommend assigning it to a person with expertise and broad knowledge of the product, such as a project manager or a product owner.
If you, as a client, move the responsibility of writing the acceptance criteria to the dev team, you may end up with a product that doesn’t fully meet your specific expectations. As a result, you may face additional expenses. You are expecting high-quality work, so you should do everything in your power to provide the team with the most comprehensive requirements and conditions so that the team can implement a user story that fits the market requirements.
Note that the team could need some more details to clarify your vision, so you or the person who represents your company should be available to answer any questions or issues that may arise. It’s in your best interest to make the story as accurate as possible. You or your representative needs to work closely with the team to enhance the AC for their user stories and understand how certain requirements will affect the product and further development, as well as what limitations and challenges the team may face.
Conclusion
A problem may be perceived differently by various team members and stakeholders. Before you start the development work, make sure that everyone involved (developers, testers, analysts, UX designers, project managers) agrees on and follows the same vision. The more information you provide to the development team, the smoother the project will run.
