A while back, I was in a scrum team’s backlog grooming session when all of a sudden one of the dev team members blurted out something about one of the user stories the team was looking at. The dev team member didn’t like the Acceptance Criteria that was created by the Product Owner, so the dev member decided to interrupt the meeting to tell everyone that Acceptance Criteria’s where waterfall, and never meant for Agile Software development. I gave the Product Owner and dev team members a chance to defend the need of the Acceptance Criteria’s we used in our stories, but everyone was silent and looked on in awe at the dev team members remarks.
Getting back on track….
The dev member went on for a couple of minutes about how bad an Acceptance Criteria was in agile development and that it was only needed for waterfall development. When I asked the dev member why they felt this way I was a bit caught off guard by the response. The dev member felt it was up to the dev team to decide how they wanted to complete the user story, and all that was needed was a brief title of the general ask. Since I had never heard such a challenge of using Acceptance Criteria’s in agile software development, and because I didn’t want the meeting to be derailed, I ensured that we get back on the agenda at hand and finished with the backlog grooming session (including reviewing the Acceptance Criteria we were given).
No matter how much time passed since that day where the dev member brought up that challenge, I couldn’t get that conversation out of my mind. From my experience and training, the Acceptance Criteria was very valuable (if not necessary) with my creation of user stories for dev teams as a product owner. Also, when I was apart of a dev team, I always looked for the Acceptance Criteria in a user story before moving forward with it.
Fortunately, I attended a Conference hosted by Scrum Alliance where there were highly experienced Certified Scum Trainers and Coaches on site providing free guidance to anyone who would come by their table in between meetings. I decided to swing by and see what the expert Agile Coaches thought about the conversation I had. After an amazing chat with a coach, I not only walked away with a sanity check and the confirmation that an Acceptance Criteria is agile instead of waterfall, but I also walked away with an even greater sense of confidence and clarity.
I’m sure there are times where we all may question the need of an Acceptance Criteria as we are faced with daily challenges. In times like these, we can dig deep and remember the examples below.
- Provides a list of conditions which helps to verify a story is Done.
- Helps avoid scrum team tension during backlog grooming sessions and help lead to a more efficient poker planning estimation.
- Sets clear expectations from the product owner to the dev team, which ultimately ensures the end user or stakeholder is getting what they want.
Thanks to the Coach who helped me get thru this scenario above. Also, check out Agile Class Rooms.