Acceptance Criteria: User Stories

• Acceptance Criteria (AC) outlines the conditions for a product, user story, or work increment to be accepted, ensuring customer expectations are fulfilled; AC is a useful tool teams may choose to use to improve the quality of product backlog items, but not part of the Scrum Guide.
• AC are pass/fail conditions and either met or not met, and never only partially fulfilled. Shortened to AC.
• Many scrum and agile teams use AC to organize work and deliver results.
• AC are often expressed as a set of statements.

Key Characteristics of Acceptance Criteria

• Clear and easily understood by everyone involved.
• Concise to avoid ambiguity.
• Testable or verifiable to ensure fulfillment.
• Focused on delivering results that satisfy the customer.
• AC illuminate the "what" of the work, not the "how."

User Stories vs. Acceptance Criteria

• User stories are brief descriptions of customer needs from their perspective, outlining their goals or problems.
• Acceptance criteria define what must be done to solve the problem or achieve the goal described in the user story.
• User stories explain the "why," while acceptance criteria explain the "what," leaving the "how" to the developers during the sprint.
• User stories and acceptance criteria complement one another.
• For some scrum teams, a user story is the smallest chunk of work that expresses a product backlog item. Some teams leave their PBIs at that.

Crafting Acceptance Criteria

• Identify acceptance criteria by understanding what the customer wants, expects, or needs from the product.
• Sources for defining AC include discussions with customers, stakeholders, product backlog refinement, sprint planning, team brainstorming, and customer feedback.
• The product owner is often responsible for writing the AC, but the development team should be involved to provide expertise and ensure alignment.
• Involve the scrum master to facilitate by identifying ambiguities, clarifying the purpose of AC, and encouraging developers to voice concerns.
• Because industries and job roles are unique, the acceptance criteria don’t always originate from a traditional customer. Instead, it may be the product owner’s or stakeholders’ criteria or those of another type of client or user.

Timing of Writing Acceptance Criteria

• Identify initial criteria during backlog refinement.
• Finalize acceptance criteria just before development begins, ideally during sprint planning.
• Just-in-time finalization ensures the use of the latest information and customer expectations.

Approaches to Writing Acceptance Criteria

• Use bullet lists, checklists, or verification lists.
• Consider a custom approach, adapting the format based on the team's needs.
• Implement the scenario-based template: "Given (context), when (action), then (result)."
• Teams can inspect and adapt the effectiveness of the AC format used during retrospectives..

Checklist for Effective Acceptance Criteria

• Clear to all stakeholders.
• Testable or verifiable.
• Pass/fail outcome only.
• Focus on outcome, not the process.
• Specific as possible.

Common Mistakes to Avoid

• Ignoring the user perspective.
• Prescribing "how" the work should be done.
• Writing AC too early or too late in the process.
• Using broad or vague criteria.
• Creating an excessive number of criteria, indicating a need to break down the work.
• Experimenting with AC and seeing what works is important when applying agile practices in the real world.

Acceptance Criteria vs. Definition of Done

• The Definition of Done (DoD) is a standard list of requirements that apply to all product backlog items to ensure they are potentially shippable.
• Acceptance criteria vary for each product backlog item.
• DoD examples: code completion, testing, no defects, live deployment.
• Acceptance Criteria examples: brand compliance, peer review, stakeholder approval.
• Instead of saying something is "done", say that something is simply "accepted"
• AC are applied to a wide array of deliverables extending beyond software products across diverse industries, from app development to human resource departments.

Value to Agile Organizations

• Improve understanding among end users, product owners, and developers.
• Clearly defines the sprint goals for developers.
• Supports agile values by being quick and concise.
• Reduces ambiguity for efficient self-managed development.
• Minimizes the risk of unfulfilled customer expectations.
• Provides specific criteria for product testing.
• AC can be created quickly and concisely, supporting the value of working software over comprehensive documentation