When working on an Agile Project, solution requirements are gathered through meetings between the customer and the Product Owner and potentially a Business Analyst. Unlike requirements from a traditional Waterfall project the solution requirements for an Agile Project are written is a simple nontechnical format that is easily consumable by all project stakeholders. Project stakeholders from the customer, nontechnical product owner and executive team to the technical implementation team members should be able to read and understand the meaning behind the simplified requirement. This plain English, nontechnical, easily consumable format is known as a User Story. User Stories follow a basic format that is consistent regardless of who writes the User Story and their technical background (or lack thereof). This simple format includes the type of user performing the action, the action they are performing and the results they hope to gain by performing said action for example:
As a customer
I want to log in
so that I can order the items in my shopping cart without reentering my information for every order.
In this example the type of user is a customer, the action is logging in and the goal is to avoid entering customer details when making a purchase. It’s a nice standard format easily understood by all parties involved but where are the details? As a developer how do I know “exactly” what the customer is asking for? As a tester how do I know what I should test for to ensure that we deliver what the customer really wants? The answer is Acceptance Criteria! Acceptance Criteria is where the details of our User Story are fleshed out through further discussion with the customer. For example, the Product Owner might ask the Customer “What information does the user not want to reenter? To which the customer might respond “Shipping address, billing address and payment details”. To further clarify the customer’s intentions for the desired feature the Product Owner may dig deeper and ask “what do you mean by payment details”. To which the customer might respond “credit card number, name on card, expiration date and CVS number on the back of the card”.
Once the Product Owner has collected enough detail that they have a firm grasp on the functionality requested by the customer the information is documented in the User Story as Acceptance Criteria. There is no requirement to use a standard format for the Acceptance Criteria, however for the same reasons we use a standard format for the User Story we should also adopt a standard format for Acceptance Criteria so no matter who writes the Acceptance Criteria it is in a consistent format that is easily understood by all project stakeholders. A good candidate for this standard Acceptance Criteria format is Gherkin format. Gherkin format is used in an acceptance testing tool called cucumber, hence the name. A Gherkin is a smaller variety of cucumber used to make pickles so it’s fitting that it is the name of the syntax used to write Acceptance Criteria in an application called “Cucumber”. Gherkin use a standard format that describes the scenario in question, the action to be performed and the expected result keeping the statement short and to the point using the Given…When…Then… format.
Given a valid username and password
When I login
Then I am taken to the profile page
Without this standard format, Acceptance Criteria could appear as a bulleted list, as a long winded paragraph with no structure or as some other nonstandard format making it difficult to consume both by technical and nontechnical team members.
During sprint planning when the delivery team is reviewing the User Stories to be committed to the sprint the team will first play Planning Poker to come to a consensus on the Story Points assigned to a User Story. Then the team will begin to flesh out the necessary tasks to get the story to its Definition of Done. It’s worth noting that typically the sprint planning meeting should be no more than 2-4 hours per week of the sprint. During this 4-8 hour planning meeting (for a typical 2 week sprint) we should expect the team to identity 60-75 percent of the delivery team tasks necessary to get the User Story to the teams stated Definition of Done. The amount of additional time necessary to identify the 25-40 percent of delivery teams task is far beyond the effort vs accuracy curve. The more detailed the Acceptance Criteria the more likely we are to capture a larger percentage of the necessary Delivery Team tasks.
Generally speaking if a User Story has more than 15-20 Gherkin format Acceptance Criteria is probably too large (an Epic) and should be sliced to make it more manageable. As the theory goes the larger and more complex the User Story, the more Acceptance Criteria it will have and the more likely we are to miss more of the detailed delivery team tasks during sprint planning.
We do not consider a User Story “Done” until, at a minimum, all Acceptance Criteria has been met.
So, write good User Stories, write detailed Acceptance Criteria and use Gherkin format to keep the Acceptance Criteria consistent regardless who writes them.
