8 Reasons Why The Product Owner and Developers Should Define Acceptance Criteria Together

8 Reasons Why The Product Owner and Developers Should Define Acceptance Criteria Together

Ethan Huang, CST

Over the past 16 years of practicing BDD/ATDD with various organizations and teams, I’ve often observed that teams assume the Product Owner is responsible for writing Acceptance Criteria. As a result, developers expect highly detailed Acceptance Criteria from the Product Owner, considering it the entry criteria for a new Sprint. These detailed criteria often evolve into a requirement specification document.

I believe the best practice is for developers, not the Product Owner, to eventually write the final Acceptance Criteria. Both parties should collaborate—brainstorming together, with the Product Owner providing thoughts, details, guidance, and suggestions on ‘how’ it should be done. The developers should then write the criteria, with the Product Owner reviewing and confirming it.

This doesn’t reduce the Product Owner’s workload. They still need to consider all details, provide initial requirements in their preferred format, and, crucially, collaborate with the Developers to co-create the requirements. During this brainstorming session—typically part of Product Backlog Refinement—the Product Owner focuses on WHAT the product feature should be, while the Developers focus on HOW to implement it.

Though many books, including The Clean Coder by Uncle Bob and The Cucumber Book, advocate for developers to write Acceptance Criteria, few Agile teams seem to follow this practice. When the topic comes up, I share my 8 reasons why developers should take on this responsibility.

1. Deeper Understanding: When developers write Acceptance Criteria, they gain a better understanding of the requirements. Writing, rather than just reading, leads to a more profound grasp of the details.
2. Breaking Down Stories: While writing Acceptance Criteria, developers and the Product Owner collaboratively break down User Stories into smaller, manageable sub-features. For example, a simple user story like “As a registered user, I want to log in to the system, so that I can access my personalized account and features security”, it might reveal over 30 Acceptance Criteria, e.g., “Remember me”, “Security Questions”, “OTP”, “Third Party Log-in”, “QR Code Log-in”, etc. When thoroughly examined, it turns a seemingly small feature into an Epic that may take several sprints to complete.
3. Informed Commitments: Developers should brainstorm key Acceptance Criteria with the Product Owner before committing to a User Story. This collaboration helps avoid over-commitment by prioritizing and negotiating the workload.

4. Early Design Thinking: Writing Acceptance Criteria initiates the design process, prompting developers to consider how they will implement the User Story.
5. Identifying Dependencies: In BDD, using Given/When/Then statements helps identify technical dependencies. For example, specifying a requirement like “Given the GPS location information is provided” uncovers the need for accurate GPS data to implement a feature.
6. Improved Estimation: Detailed Acceptance Criteria with clear boundaries make it easier for developers to estimate the effort required to complete a User Story. If the Acceptance Criteria are detailed enough, usually the easiest way to estimate the user story is by counting the number of Acceptance Criteria.
7. Shared Ownership: When developers write Acceptance Criteria, they share ownership of the requirements with the Product Owner. This collaboration fosters a stronger partnership, breaking down the “us vs. them” mentality.

8. Product Owner Efficiency: With developers handling the documentation, the Product Owner can focus on more strategic tasks, especially as the team begins using ATDD tools like Cucumber.