So in the past all teams I've been on that used user stories have been dealing with acceptance criteria in one of two ways; either the product owner writes them or the team does it during planning.
When the product owner writes acceptance criteria for each user story I've seen a lot of variance. Sometimes the acceptance criteria is really easy to understand an measure and sometimes it is really bad. A lot of the time the acceptance criteria are written in a way assuming the implementation is going to be in a certain way. A way defined by somebody not working on the story. Regardless I often see confusion and user stories that are not accepted because something was interpreted differently than intended.
When the team writes acceptance criteria during planning sadly enough I've only seen the most senior (and/or managers) team members be involved. And the result is essentially the same as when the product owner wrote the acceptance criteria, except maybe the confusion is a little less.
So what my current team is doing right now is an interesting variant. During planning the team identifies an "owner" of the user story. This is a person who most likely will do most of the work but not all the work. This owner now is responsible for writing an acceptance criteria that is then reviewed and accepted by product owners and the rest of the team. At first this may not look like a big difference than what I described in the previous paragraph but it is. Emphasis is on having the person actually doing the work write the acceptance criteria as a validation that the user story is fully understood.
And why is this important? Well let me ask you; how many times in your life have you said "let me repeat that in my own words to make sure I understand what you mean"? Something frequently used by the military (last paragraph under "orders" section) in order to make sure the people actually doing the work understand what you want them to do.
Who writes acceptance criteria on your project and how is that working for you?
Post a Comment