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 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 so I see only that data throughout the dashboard.
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.
