Who should write Acceptance Criteria in a project delivered using Scrum Methodology

Question

We are a consultancy delivering projects for a number of our clients. For some clients, there is a Product Owner who writes the user story and the acceptance criteria (I understand that Acceptance Criteria are not mandatory, but we generally advise them as we work with a variety of resources in a distributed setup so having detailed Acceptance Criteria is always helpful).

It is generally accepted by everyone that Acceptance Criteria should be available before the development of the work begins. The question is around who should be writing the Acceptance Criteria.

I am of the opinion that the Product Owner writes the User Story describing the feature request and the Acceptance Criteria should be a collaboration between the development team (developer or tester) and the Product Owner and not necessarily handed entirely off to the Product Owner.

So, it would be something along these lines.

User Story As a contact centre agent I want to capture basic information about the customer when they call in

The Acceptance Criteria should be

1. Data Capture

1. First Name
2. Last Name
3. Date of Birth
4. Phone Number
5. Address
6. Purpose of Call (this should be in a Phone Call record)

2. Validation

1. Phone Number should be a valid UK number
2. Address should be a valid UK address (use a lookup service)
3. They are over 18 years of age
4. Last Name is mandatory

The Acceptance Criteria can be written by the Product Owner but it can also be written by the developer / tester as long as it is signed off by the Product Owner.

A colleague mentioned that the problem with asking the developer / tester to write the Acceptance Criteria is that it is additional work. They also mentioned that there is no process to capture that the Product Owner has signed off on the Acceptance Criteria so they might turn around and say that is not what we asked. (The second part of the concern is probably not agile-related and is more related to when we work as a consultancy).

So, who should write the Acceptance Criteria - is it the complete responsibility of the Product Owner or is it the team's responsibility?

Answer 1

It should first be said that there are no hard and fast rules on this. That said, the most successful teams I see operate as you describe. Specifically, the PO creates a backlog item with initial acceptance criteria and shows it to the team in backlog refinement and if needed, they collectively create more.

And while the backlog item should be "ready" before development starts, it is not uncommon that the act of development and testing uncovers new questions which require the PO's input and the answers to those may result in updated acceptance criteria.

The Scrum Guide is pretty clear on this point:

"The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable."

Your colleague made a point about creating acceptance criteria being work, and it is. The challenge is that scrum looks at development as a team effort where everyone is involved in all types of work. Understanding the right thing to build is just as important as the act of building it, and involving the development in that activity helps build that understanding.

The other thing your colleague mentioned was about process. For most teams, the fact that those are written in a backlog refinement with both team members and PO means that you can be virtually certain that the PO is aware and signed off. That said, if in your case you need something more concrete, most online process management tools allow for modified workflows. For example, I know it is possible to custom flows in Jira that would ask a PO to click a button signing off on the change in the user story description was updated. I expect many other tools can accomodate this process for you too. It may be a fair business concern for you, but it shouldn't be hard to overcome.

Answer 2

The Acceptance Criteria is about usability. When a feature meets the acceptance criteria, then for sure it can be used. The acceptance criteria is as clear as black/white.

See this video, please: https://www.scrum.org/resources/definition-done-vs-acceptance-criteria

Now, anyone can write a User Story and put it in the Product Backlog. Each user story needs to be refined before it can be selected into the Sprint Backlog during Sprint Planning.

This means that each user story written by anyone is discussed during the Product Backlog Refining meeting by the Development Team and the Product Owner. Both the development team and the product owner write the acceptance criteria.

In practice, the user story already contains the acceptance criteria when it enters the Sprint Planning meeting or the acceptance criteria it is defined during the Sprint Planning by the Development Team and the Product Owner.

A colleague mentioned that the problem with asking the developer / tester to write the Acceptance Criteria is that it is additional work.

This work is done either during the Product Backlog Refinement or Sprint Planning.

They also mentioned that there is no process to capture that the Product Owner has signed off on the Acceptance Criteria so they might turn around and say that is not what we asked.

If it's suggested by the Product Owner to be taken into the Sprint Backlog by the Development team, then we know that the Product Owner has read and agreed to the Acceptance Criteria of the User Story.

Obviously, the acceptance criteria can evolve during the Sprint. Any modifications should be discussed on the fly by the Development Team and the Product Owner.

There's no time to wait for the next Product Backlog Refinement. The User Story has already been selected to be delivered this Sprint so the discussion needs to happen ASAP.

That's why the Product Owner should always be available for the Development Team. And that's why there is no "sign off" in Scrum/Agile. Because any feature might suffer modifications when the Development Team actually starts implementing it.

The Product Owner should acknowledge this ASAP and clarify, based on the new information, what does it mean "the feature is usable".

For example:

A user story is about making something visible on the user interface.

In practice, this makes the user login take 5 seconds more due to a big, slow request against the backend. So, the user story could be delivered as it is, but is it usable?

Is it acceptable for the user login to take 5 seconds? This is a question for the Product Owner.

What's the alternative? The Development Team claims it needs to optimize the backend request and wants to increase the complexity from 2SP to 3SP. In return, this means that another User Story might not be delivered.

What should be done? Choices for the Product Owner: 1. Deliver the User Story as originally described, accepting the added 5 seconds login time. 2. Update the User Story to 3SP and optimize the backend request, esentially giving this User Story higher priority than another one (which might not be "Done" this Sprint). 3. Deliver other user stories first, then start working on this one, upgrading it to 3SP and possibly not delivering it this Sprint.

The Product Owner needs to consider the new information ("5 seconds user login delay") and decide on the spot what to do.