Answer.

Historically, the formulation of acceptance criteria has been left to testers or the development team. However, with the transition to agile scaling processes (SAFe, LeSS, Scrum-of-Scrums), the lack of formalized testing scenarios poses risks of divergent expectations among different participants in a large project: business, testing, developers, and support may interpret task completion differently.

The problem in multi-team or distributed projects is the various areas of responsibility, differing processes and tools, and language or cultural differences between teams. Even well-defined requirements can lead to conflicting or incomplete acceptance criteria, resulting in bugs and business dissatisfaction.

The solution is to involve the systems analyst early in the formation of acceptance criteria, facilitate the alignment of requirements between teams, and rigorously formalize and jointly discuss scenarios and edge cases in a joint demo or group workshop.

Key features:

Acceptance criteria should be unambiguous, measurable, reproducible, and verifiable.
Preliminary agreement on criteria (manual checklist + examples of expected data/behavior).
Mutual traceability: criteria should always reference requirements, cases, and user stories to track each goal.

Trick questions.

Can the formulation of acceptance criteria be left entirely to testers?

No, the analyst must participate. Only they possess the complete business context and know all the nuances of the requirements.

Should acceptance criteria only cover positive scenarios?

No, negative and edge cases must be included; otherwise, gaps in implementation and testing may arise.

Can acceptance criteria be defined verbally in multi-team projects?

No, verbal agreements cannot withstand the pressures of distributed interaction and lead to conflicts. Criteria are only accepted in a formalized manner (e.g., in the form of Gherkin/BDD or structured checklists).

Common mistakes and anti-patterns

Formulating acceptance criteria "by default," without references to requirements and specifications.
Lack of feedback from end teams.
Ignoring interaction scenarios between components of different teams, especially during integrations.

Real-life example

Negative case: In a banking application, acceptance criteria for the transfer functionality were agreed upon only with one team. The second team implemented its internal interfaces without considering the first block of criteria, resulting in discrepancies in transaction ID formats.

Pros:

Quick start of implementation.

Cons:

Need to refactor the API.
Time lost in resolving collisions.

Positive case: The analyst conducted a series of workshops with visual scenarios and details for all participating teams, with mandatory written documentation of acceptance criteria in Confluence/JIRA with bidirectional traceability to requirements.