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
Feb 14, 2021

Reflecting on the 20th anniversary of the Agile Manifesto

Enterprise Agile Planning
Over the past 20 years, it’s been amazing to watch an idea from ...
Read More
Feb 08, 2021

How does agile apply to an entire organization?

Enterprise Agile Planning
Before we dive into the main subject of this blog post, it is importan ...
Read More
Feb 03, 2021

It took a pandemic to realize why digital transformation actually matters

Enterprise Agile Planning
Before anyone had ever heard of COVID-19, businesses across the globe ...
Read More
Jan 27, 2021

Improve visibility, reduce costs, and take back control of your scaled out container and cloud deployments with the latest releases of Digital.ai Agility and DevOps solutions

Enterprise Agile Planning
We’re thrilled to announce the latest releases of our Digital.ai Agili ...
Read More
Contact Us