Agile Acceptance Criteria

I’ve been hearing a bit of confusion about acceptance criteria lately and I wanted to clarify a couple of things.

Ultimately, the point of acceptance criteria is to establish the definition of done. We talk about defining done in Agile so that teams know exactly what to create. We try to, well let’s just say, “control” gold-plating by offering this definition of done. I believe that in using the “Given, When Then” format, we are also helping testers determine when to begin and end the testing for that specific independent feature.

So the format would look something like this:

User Story:

As an executive, I want to be able to filter the dashboard by department so that I can isolate data by a specific department.

Acceptance Criteria:

  • Given the Executive Dashboard default view, when I select the department drop-down, I have the ability to select a specific department to so only that data throughout the dashboard.
  • Given the department drop-down, when I select a specific department, the entire dashboard filters to display only that department data.

In grooming sessions/workshops, I would expect this basic information to garner discussion and questions. The result of the first grooming session should be perhaps a sketch as well as some questions such as:

“Hey Product Owner, does the Executive need to be able to Multi-select several departments?”

“How about grouping by division?”

During this discovery, we might find out from the technical influence in that Grooming Team that coding for Multi-select would make this story much more complex and maybe even too complex to complete in only one iteration. This conversation would then offer the Product Owner the opportunity to decide to make the multi-select option a second story.

From the testers perspective, the ‘Given’ (Given the Executive Dashboard default view), has established where the testing begins and help determine what acceptance tests to create. So more discussion is likely going to happen and assumptions will be documented, such as security: who can access the Executive Dashboard, etc. Additionally, this direction helps testers go back to look at anything they might have missed that should be a regression test.

Always consider where the testing should begin (Give a state) and where it should end (So that a specific result is experienced). Conditions of Satisfaction should include assumptions and alternatives.

This entry was posted in Agile Development, Agile Methodologies, Agile Project Management, Agile Testing, Scrum Development, Scrum Methodology, Test Driven Development, Uncategorized. Bookmark the permalink.

3 Responses to Agile Acceptance Criteria

  1. Jim Cook says:

    The big lesson in what you write is “involve the testers as early as possible.” If they really come in at that point you get a triple benefit – more refinement to the requirements, better understanding of the story, AND well defined acceptable criteria.

  2. Ron Gliane says:

    Where would you suggest inserting the Conditions of Satisfaction text? In the backlog story (or epic) description field, a custom field, or an associated Test?

    • Steve Ropa says:

      Hi Ron,
      Me, I like to think of each Condition as a test that can and should be automated. So in VersionOne I like to insert each condition as an associated Test.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>