Agile Acceptance Criteria

November 14, 2013 CollabNet VersionOne

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.

Previous Article
The Agile Coach on Identity
The Agile Coach on Identity

I am a Java Programmer. I am a User Experience Designer. I am a Quality Assurance Analyst. I am a Business ...

Next Article
Free Workshop in DC: Steps for Achieving Agile and DevOps Success
Free Workshop in DC: Steps for Achieving Agile and DevOps Success

On December 5th in Washington, DC, CollabNet along with their partner Carahsoft, a government IT solutions ...