Who should be writing acceptance criteria?
I hear contradictory views on the internet.. I was under the impression that it is Product Owner's responsibility though it is a collective work but a lot of material on the internet suggest it should be Dev.
Can any one provide your experiences with your teams?
Do written acceptance criteria help the Developers to estimate the work and ensure that it is ready for Sprint Planning, or are they serving some other purpose?
There is no mention in the Scrum Guide of Acceptance Criteria. In fact, there is no guidance at all about how to compose a Product Backlog Item. It is said that the act of refinement is an activity that adds details such as description, order, and size.
How a Scrum Team chooses to capture the information for their Product Backlog is entirely up to them. Being a self-organized and self-managed team, they can decide on how the Product Backlog items will provide the details and what details to provide.
All of the opinions you read on the internet about User Story formats are just that. Opinions. There is no definitive answer. So with your team work to form an opinion that your team can all agree to and support.
Normally, the owner of the story defines Acceptance Criteria but not always necessary. PO or Dev can do the same by knowing the definition of from the story owner to define Acceptance Criteria properly.
Question: Scrum Master is a facilitator. Should Scrum Master involve in this activity?
Why does it have to be a single person's responsibility to find and document acceptance criteria?
It is true that the Product Owner is accountable for "creating and clearly communicating Product Backlog Items", and since acceptance criteria capture what and how a product behaves in order to be acceptable to stakeholders, it makes sense that the Product Owner is ultimately accountable for ensuring that the acceptance criteria is clear and consistent. However, there are many points in time where acceptance criteria can be discovered - from the initial conversations (which, in my experience, are often between the Product Owner and the stakeholders) all the way through design and implementation.
Everyone on the team is responsible for ensuring that what the team builds is acceptable to key stakeholders, regardless of how those criteria are documented.
If the Definition of Done for an increment is a part of the organization's standards, all Scrum Teams should follow it as a minimum. If it's not an organizational standard, the Scrum Team must create a Definition of Done appropriately for the product.
Question: Scrum Master is a facilitator. Should Scrum Master involve in this activity? - Yes
Given the above extract from the Scrum Guide, The Scrum Master is part of the Scrum Team.
What we have adopted in our team is that the person writing the User Story will write down the acceptance criteria as per his or her understanding at that moment.
When the Story is being discussed the Team discusses and modifies the acceptance criteria if required. A change in acceptance criteria can possibly lead to rework and a well defined acceptance criteria could minimize this.
"Who defines the acceptance criteria" is left to the each team/organization as Scrum guide has no specific recommendation.
Following the philosophy of self-organizing, self-managing Scrum team with accountabilities of SM, PO and Developers my recommendation would be as below, which worked pretty well for teams I worked with.
During Backlog refinement the team adds acceptance criteria. PO provides clarity on the business need and value while entire scrum team (Note: PO and SM could also be developers) agrees on what the acceptance criteria for that PBI(Story, etc.,) should be.
Anyone can volunteer to scribe and add acceptance criteria. The team can also take turns to avoid any bottlenecks for this activity. Also it is better to add the acceptance criteria right when the discussion and conclusions are made. This will make the product backlog more transparent to all team members.