What are some examples of good and bad acceptance criteria for complex systems?

Additionally, good acceptance criteria provides context to the user needs and scenarios by outlining the conditions, action, and results. For example, for a user story about a user writing a comment on an article: The conditions would be: The user is logged in and viewing the article, and the user has selected to contribute to the article. The action: The user provides their contribution text The results: The user is able to save their contribution, the user can see the characters remaining in the 750 character limit. The Conditions (Given), Action (When), Results (Then) are a great structure that helps all roles and stakeholders understand the scenario of the user story. Each user story can have multiple scenarios in scope.

Good acceptance criteria are clear, concise, testable and measurable — they act as a single source of truth for the team. For complex systems, they define scope, expected behavior, and constraints while accounting for edge cases and dependencies. Strong criteria ensure alignment between stakeholders, developers, and QA, reducing ambiguity and scope creep. They focus on user value and business outcomes, making sure every feature meets a real need. When acceptance criteria are well-defined, they drive efficiency, quality, and collaboration — setting the foundation for seamless execution.

Shouldnt define the solution. The criteria should speak only the end user expectation from an E2E perspective to solve the user story. Solution should be identified based on the criteria and problems to be solved for, by the engineering design process.

Bad acceptance criteria are subjective, and incomplete — they create confusion and misalignment. Statements like “The system should be user-friendly” lack specificity and leave too much room for interpretation. In complex systems, missing edge cases or ignoring dependencies can lead to costly rework and delayed delivery. Poorly defined criteria often fail to capture non-functional requirements like performance, security, and scalability. When acceptance criteria lack clarity, they sabotage quality, efficiency, and the team’s ability to deliver real value.

From my experience, I could add that Acceptance Criteria (and other user stories/task/document descriptions) should be comprehensive and sufficient. it means that it should be clear, and consists of all necessary information, with proper phrasing (abovementioned 'avoid jargon or acronymic'). One crucial point is that Acceptance Criteria should be measurable and achievable.

Writing good acceptance criteria requires collaboration, precision, and a deep understanding of user needs. Use formats like Given/When/Then to describe behavior in different scenarios clearly. Capture functional and non-functional requirements, and ensure criteria are measurable and testable. Prioritize user value, performance, and quality while addressing constraints and dependencies. In complex systems, involving stakeholders early and validating understanding ensures criteria align with business objectives and technical feasibility — setting the stage for success.

A common challenge teams have is when the acceptance criteria (a/c) are dependent on other systems/components. For example: trying to write a/c for an API, data feed, database, or other technical component. This does not work well because the users and business stakeholders cannot "accept" it partially constructed. A/C is about the end users accepting the solution as usable, so it must be relevant to an increment that is usable and acceptable, rather than a component of a system/solution. It's a best practice not to write a/c for a single component dependent on other pieces to deliver value to end users, even if it is the only component being updated, it still gets "accepted" when integrated with other parts of the usable solution.

I’ve found that when writing acceptance criteria for API integrations, that it’s best to state the specific data points needed to verify that the integration is working.

Avoiding bad acceptance criteria starts with proactive collaboration and ruthless clarity. Engage stakeholders, developers, and QA early to gather diverse perspectives and prevent blind spots. Break down large features into smaller, testable units and ensure every requirement is specific and measurable. Avoid assumptions — validate understanding through discussions and documentation. In complex systems, aligning on edge cases, constraints, and dependencies minimizes scope creep and rework. By fostering transparency and shared understanding, you set the foundation for consistent quality and delivery.

Testing acceptance criteria means ensuring they’re clear, complete, and directly tied to user and business outcomes. Walk through each criterion with developers, QA, and stakeholders to confirm shared understanding and feasibility. Check if the criteria are independently testable and cover both happy paths and edge cases. In complex systems, map criteria to user stories and business requirements to ensure alignment. Validating non-functional aspects like performance and security is crucial. Strong acceptance criteria pass this test by being actionable, measurable, and essential for quality delivery.