It's a loaded question — partly because it assumes you're even using acceptance criteria in the first place, and partly because the obvious answer isn't the right one.
Let's unpack both.
A Quick Refresher on Acceptance Criteria
Acceptance criteria usually show up alongside user stories. A user story typically reads something like: in order to deliver a particular kind of value, this persona wants or needs this thing. Underneath that, you list the acceptance criteria — the conditions that, if they were all in place, would make you happy calling the work done.
Some of those criteria are functional. Others are non-functional: the work needs to comply with a particular international standard, or perform within a certain time window, or meet some specific quality bar.
They're genuinely useful. When the team picks up a work item, acceptance criteria give them a clear sense of what "done" actually looks like.
Given, When, Then
One of the most powerful ways to write acceptance criteria is the given-when-then format — the backbone of specification by example, behavior-driven development (BDD), and automated acceptance testing.
Given a particular context, when certain events happen, then this is what we expect to happen.
It's precise, testable, and it forces clarity about the behavior you actually want. If you haven't tried framing acceptance criteria this way, it's worth experimenting with.
So Who Actually Writes Them?
Here's where people often get it wrong. You might assume the product owner writes acceptance criteria. They don't — or at least, they shouldn't.
The people doing the work write them.
In scrum, that's the developers. In a Kanban system, it's the Kanban system members. The folks who will actually build the thing are the ones who write down what "acceptable" looks like.
Why Not the Product Owner?
Because the product owner has a different job to do, and it's a big one.
A product owner should be working with customers and stakeholders, managing expectations about uncertainty, and helping people accept a hard truth: some of the work they're asking for may realistically never happen. There are competing priorities. Battles have to be picked. What's going to get attention this sprint, this month, this quarter, this year — those are the conversations a product owner should be having.
If the product owner is also the one drafting acceptance criteria, two bad things tend to happen. First, they're pulled away from the stakeholder work only they can do. Second, a dysfunctional pattern creeps in where developers start pushing back with, "No, you can't bring this in — it's not ready." That's the wrong conversation at the wrong time.
Readiness Is the Team's Job
The last chance to get a work item ready is inside the team's own process — sprint planning in scrum, replenishment in Kanban. Those are the moments where the team collectively confirms a work item is clear enough to pull in. There's really no need for someone outside the team to be writing these items in advance.
When the team writes its own acceptance criteria, readiness stops being a blame game. It becomes part of the work.
The Short Version
Acceptance criteria are valuable. Given-when-then makes them sharper. But the people who write them should be the people doing the work — not the product owner. Keep the product owner focused on customers, priorities, and trade-offs. Let the team own the definition of what "done" looks like for the work they're about to do.
Share:
Setting Expectations in Scrum
What is Cycle Time?