As we have seen, product owners act as a conduit between the business and/or customers and the team. The product owner’s role encompasses not only the definition of what gets done and when, but also the level of quality of what gets delivered.  One of the facets of the role affecting quality comes when the product owner participates in writing the acceptance criteria for user stories.  Acceptance criteria are part of well-formed user stories and are crafted early in the life cycle when stories are generated and refined as they are groomed.  The product owner role provides another check on quality and occurs when the product owner uses his or her authority to accept completed stories.  I don’t want to suggest that the product owner is only active at the start and end of a sprint or iteration. The product owner interacts with the team on a continuous basis in order to guide the work and the culture. Adoption of acceptance test-driven development (ATDD) is an excellent method of instantiating the product owner’s role in both shaping the vision for the team and influencing the quality of the work a team delivers.

The Test Obsessed blog states, “Acceptance Test Driven Development is a practice in which the whole team collaboratively discusses acceptance criteria, with examples, and then distills them into a set of concrete acceptance tests before development begins.” The product owner is the central cog in the ATDD process that we have examined in an earlier essay (Acceptance Test Driven Development).  At a high level, ATDD begins by generating a set acceptance test cases for the user stories as they are defined and refined.  The cases or examples are done before coding on the story begins. The cases are a type of example that ensures everyone on the team has the same understanding of what is being built and provide a mechanism for understanding what the customer expects. ATDD provides the product owner and team a path to ensure that the right things are getting built.

Acceptance tests written in advance of coding will always provide additional depth to a user story or the requirements which further supports delivering a quality product.  ATDD is a development technique, a testing technique, and collaboration technique. The acceptance cases begin life as a tool to develop shared insight amongst the team then transitions into a tool to provide input that is useful for developing the code and finally as the expected results of acceptance testing. The product owner acts as the voice of the customer and controls the flow of the process through their ownership of the backlog (defining, prioritizing, and accepting results). As the voice of the customer and an interface to the business, the product owner has to answer for what gets done and how well it gets done.  ATDD is a tool for the product owner to build quality into the Agile process.