Who writes the acceptance criteria?

Who writes acceptance criteria?. Should you even have acceptance criteria? It’s a loaded question, because it’s assuming that we’re using user stories. And in user stories typically you might say in order to deliver a particular type of value, some particular persona wants or needs something in order to do so, and then you typically list off your acceptance criteria.

These are the things that if they were in place, I would be happy with it. And then you might have some non-functional acceptance criteria. It needs to comply with a particular international standard, or it needs to perform it in a particular period of time. Acceptance criteria are very useful because when the team is working on the work item, they have a sense of what work they need to do to help to deliver that.

You can actually use specifications by example. “Also given this situation given a particular context when certain events happen, this is what we expect to happen”. Behavior-driven development, automated acceptance testing, specification by example, these are all very good ways of using the ‘given when then’ format.

That’s a lovely way to write your acceptance criteria, but who writes them? The people doing the work write them, not the product owner. You thought it was the product owner? I want the product owner to be working with the customers, the stakeholders, managing their expectations about uncertainty, helping people to realize that some of their work realistically may never happen.

Maybe there’s multiple priorities here and that we need to be picking our battles in terms of what we’re going to target right now in the next month and the next quarter, in the next sprint of years in scrum. So actually the developers, the people doing the work in scrum or the Kanban system members in Kanban they would write these items. They would write the acceptance criteria. And I much prefer that because if a product owner, for example, is writing these items with the acceptance criteria, there can be a behavior from developers or kanban system members with the saying, “no, you can’t bring this in cause it’s not ready”.

That’s bad behavior from my point of view because the last chance for getting work ready is in sprint planning in scrum and in replenishment in Kanban; there’s really no need for a product owner or someone outside the team to be writing these items.

https://linktr.ee/johncolemanxagility — social and podcast links

https://linkpop.com/orderlydisruption — order training from right here