Skip to main content
Enterprise Agile Planning Image

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Nov 14, 2013 — Enterprise Agile Planning expert

Agile Acceptance Criteria

Enterprise Agile Planning

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.

More from the Blog

View more
Jul 27, 2021 Becomes First to Achieve FedRAMP Moderate “In Process” Status for Enterprise Agile Planning Solution

Enterprise Agile Planning, the leading AI-driven DevOps value stream delivery, and ma ...
Read More
Jun 21, 2021

How Agile can be implemented effectively across the organization

Enterprise Agile Planning
Just a few decades ago, a “disruption” was seen as an undesirable thin ...
Read More
May 31, 2021

Agile change management processes are key to delivering software faster

Enterprise Agile Planning
With its emphasis on delivery value faster, agile product management s ...
Read More
May 03, 2021

Bringing the agile planning approach to your whole business

Enterprise Agile Planning
The events of the last 12 months have demonstrated that the only sure ...
Read More
Contact Us