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.
- 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:
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:
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:
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
Agile Ninja, Gilli Aliotti, leads agile coaches, scrummasters, scrum product owners, tech disrupters and lean startup entrepreneurs to become “agile warriors” in their careers and lead their teams through rockstar agile transformation. All articles are © Copyright of the Author and this site www.theagilewarrior.com and cannot be reprinted or distributed without permission. If you would like to re-post these articles, please contact us. Or you can tap the social share buttons to share these blogs, with links intact, to your network.