Skip to main content
Enterprise Agile Planning icon with arrows

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 Government Cloud
Apr 12, 2022 Government Cloud receives FedRAMP Authorization through sponsorship from the United States Department of Veterans Affairs

Enterprise Agile Planning
Flagship Agility solutions can effectively scale agile deve ...
Read More
Nov 22, 2021

What are the qualities of highly effective agile teams?

Enterprise Agile Planning
A team is the core unit of productivity in an agile organization. Wher ...
Read More
Nov 15, 2021

How an open-first attitude revolutionized government tech development

Enterprise Agile Planning
Public perception of government is often that it is slow-moving, reluc ...
Read More
cross functional
Nov 08, 2021

6 best practices for building resilient cross-functional teams

Enterprise Agile Planning
Agile frameworks prize the quality of resilience within every facet of ...
Read More
Contact Us