Acceptance Criteria and why it's important for User Stories and the success of teams

Why do we need acceptance criteria?

Having acceptance criteria is critical for the success of the story to complete, and quite frankly, for the success of a high performing scrum team. The team must be responsible for their own definition of Done of a sprint.

Happy Reading! Tap on Read More below.

---

Before we get into AC, let's take a look at some other important definitions:

Definition of Ready 
 "when user stories are at a state to be actionable. The scrum team are clear on what needs to be done and the amount of work required to complete the user story or PBI (product backlog item). "The Team must understand the "done" criteria and what tests will be performed to demonstrate that the story is complete. "Ready" stories should be clear, concise, and most importantly, actionable." - ScrumInc.com


Definition of Done 
"drives the quality of the work to meet the acceptance criteria. These are standards that each scrum team agree to, in order to meet the acceptance criteria across all user stories for the sprint.  In software, this may be: “Done means coded to standards, reviewed, implemented with unit Test-Driven Development (TDD), tested with 100 percent test automation, integrated and documented. In a services context, it might look something like this: "Done means every task under the User Story has been completed and any work created is attached to the User Story so the Product Owner can review it and make sure it meets his or her expectations." - ScrumInc.com


Writing good user stories is critical to the "Definition of Ready" for stories to be planned in sprint, but without good Acceptance Criteria, the story, and the team, are set up to fail.

Example user story: As an Administrator, I want to be able to create User Accounts so that I can grant users access to the system.

The above cannot stand alone. It must be accompanied by "good"ACCEPTANCE CRITERIA to clearly demonstrate if the team have indeed made the user story come true. 
What is Acceptance Criteria?

Acceptance Criteria (AC) are the “conditions that a software product must satisfy to be accepted by a user, customer or other stakeholders.” (Microsoft Press).
Google defines them as “Pre-established standards or requirements a product or project must meet.”

It defines how a particular feature or desire could be used from an end user's perspective and focuses on business value. The AC establishes the boundaries of the scope and guides development. Without AC, the scrum team often lack clarity, or interpret differently, what connotes acceptance for a story or PBI. In my world, I've seen multiple cat fights over what is acceptable to mark a PBI 'done' in a sprint, and this is exclusively around the confusion or non-clarity and lack of agreement of what "acceptance" means.

Therefore, AC is critical for the success of the story to complete, and quite frankly, for the success of a high performing scrum team.


AC are

-  unique to an Epic or user story and form the basis of user story acceptance testing which establishes the conditions for the success of the feature.

- establishes a boundary that helps team members to understand what’s included and what’s excluded from the scope of the user story. 

7 Tips for Writing Acceptance Criteria:

1. Every story or PBI (product backlog item) should have at east 1 AC. Do not skip. 
   • AC should be added to our Epics and User Stories before the work gets started, as part of our "definition of ready", meaning, this is ready to begin work.
2. Write the AC before start of sprint. If you write after implementation you miss the benefits, and team is confused on definition of done.
   • Ideally AC is written by the Product Owner but is a collaborative effort, together with the scrum members - developers, QA, designer, and where appropriate for us, video engineer, data scientist. In writing it together, it fosters consensus on the AC as well as full understanding of the desire. It also takes the pressure off the PO in case he/she missed a detail and will be informed by the team about the complexity and level of effort.
   • Typically user story writing, along with its acceptance criteria, is drafted then "groomed" in regular "Grooming Sessions", a scrum ceremony, (and in Agile SAFe, also in the Big Room Planning Meeting of the Program Increment (PI)).
3. Each acceptance criterion is independently testable.  
4. Acceptance criteria must have a clear Pass / Fail result. Write complex and long sentences at your own risk.
   • The criterion of user story acceptance not only informs the product behavior in happy path scenarios, it also guides the user experience when things don’t work as intended. It describes what would be verified by the acceptance tests which is particularly helpful for QA Engineers- When the product owner verifies particular user story acceptance criteria and the developed feature passes it, the development of the user story is considered a success. Pass / fail type results allow AC to form the basis of creating tests that can be automated and executed.
5. It focuses on the end result – The What. (Not the solution approach – How). This is a big miss by teams. Product owners sometimes think they need to spoon feed the technical how to get there. But it's up to the team to go figure that out based on their expertise.
   • Acceptance Criteria should state intent, but not a solution (e.g., “A manager can approve or disapprove an audit form” rather than “A manager can click an ‘Approve/Disapprove’ radio button to approve an audit form”). The criteria should be independent of the implementation: ideally the phrasing should be the same regardless of target platform.
6. Include functional as well as non-functional criteria – when relevant.
   • If we are design-first in our experience, an acceptance criterion could be based on a styleguide that fosters synergistic user experience.

What should be in AC?
Acceptance Criteria may reference what is in the project’s other User Stories or design documents to provide details, but should not be a re-hash of them. They should be relatively high-level while still providing enough detail to be useful. They should include:

• Functional Criteria: Identify specific user tasks, functions or business processes that must be in place. A functional criterion might be “A user is able to access a list of available reports.” A non-functional criterion might be “Edit buttons and Workflow buttons comply with the Site Button Design.”
• Non-functional Criteria: Identify specific non-functional conditions the implementation must meet, such as design elements. A non-functional criterion might be “Edit buttons and Workflow buttons comply with the Site Button Design.”
• Performance Criteria: If specific performance is critical to the acceptance of a user story, it should be included. This is often measured as a response time, and should be spelled out as a threshold such as “1-2 seconds for a query response.”

7. Team members write acceptance criteria for stories and the Product Owner verifies it. It confirms the PO and the team have shared understanding of the user story. However in our Quarterly PI planning world, we'd like PO to write loose, simplified AC for Epics before going into breakouts. Then the team can flesh it out together as stories are built for the quarter.


Side note: When adding AC to EPICS
Because Epics are basically really large user stories, you may be adding acceptance criteria about the Feature. Sometimes, as AC is fleshed out, these help to create the user stories, which in turn represent an AC from the Epic, and therefore are independently testable.  Therefore, Epics with ACs become a great way to figure out what Stories to write, in figuring out the happy path to build the feature.  

Let's revisit the User Story Example
The Example user story: As an Administrator, I want to be able to create User Accounts so that I can grant users access to the system.

Acceptance Criteria for the above User Story  might look like the following:

• If I am an Administrator, I can create User Accounts.
• I can create a User Account by entering the following information about the User: a. Name, b. Email address, c. Phone Number d. License Number (Power/Basic/None), e. Account Status (Active/Inactive), f. Reports to (from a list of “Active” Users)
• I cannot assign a new User to report to an “Inactive” User
• I cannot assign a new User to report to a User if it creates a cyclical relationship (e.g., User 1 reports to User 2 who reports to User 1
• The system notifies me that it sent an email to the new User’s email address, containing a system-generated initial password and instructions for the person to log in and change their password.
• I am able to verify with the intended recipient of the email that it was received.

Success of team
Finally, a point about the success of teams - when a team is clear on, and agrees to, the acceptance criteria of a story, there are seldom any more cat fights over what is acceptance and what is not acceptable. Documenting our acceptance criteria, and the pass/fail of the tickets in acceptance phase of sprints, allows the teams to communicate better, agree to the MVP of the story, and remove impediments to done. 
Clarifying what is acceptable, as much as we can upfront, ensure we get to the end successfully, in a cohesive, frictionless manner.



Hope you liked this.  


Agile Ninja Gilli