Mastering Acceptance Criteria
Creating superior acceptance criteria can build better communication for you and your teams.
Some of my Slalom team members and I recently attended Southeast Dreamin’, a Salesforce conference in Atlanta that allows professionals to share and expand their knowledge in Salesforce and Salesforce-related technologies.
The conference consisted of hands-on workshops, trainings, and info sessions with focuses on topics from project management to apex techniques. Over the course of two days, more than 200 Salesforce partners, customers, and experts attended a selection of 49 sessions.
My session, Acceptance Criteria: Your Secret Weapon to Success, quickly became one of the highest-attended sessions at the conference. In this blog post, I’m diving into some of the key takeaways from that session and providing tips on how to standardize your acceptance criteria so that it’s clear and concise for your teams.
Piece of cake — or pie?
I didn’t realize until speaking with some project leads and other colleagues that writing acceptance criteria could be sparse, too complex to understand, or nonexistent. We had all run into the same issues when creating user stories and giving them substance that helped support the functionality needed.
When I considered how I could make this content more relatable and easier to remember, I was set on comparing user stories and the acceptance criteria to something visual — with pieces that fit together to produce one result. I instantly thought of a food reference. Cooking food, or eating it, is always relatable. When you think of a user story, it’s really a placeholder or “outer layer” while the substance (the persona, description, and acceptance criteria) lives inside it. Voilà — it’s a pie!
The user story is the crust. It’s the base that holds the ingredients. The filling is where you can find the persona of the user who needs some functionality and the description of what that user should be able to accomplish after this functionality is complete. The acceptance criteria gives the conditions that the user story needs to be considered true. It’s the potpie filling or blueberries (whatever type of pie you like).
The feedback I received after using the pie analogy was great. I found a way to help make acceptance criteria more effective in user stories. I also gave examples of how it could be used to help each role on a project team, while also offering helpful tips on writing acceptance criteria.
What is acceptance criteria?
Acceptance criteria lives in a user story. A user story describes the scenario or operation and depicts the software requirements in a way that is tangible for end users. It is meant to be a conversation piece and holds the information that will help a project become successful.
The user story provides the who, how, and why: who wants the functionality, how should it be used, and why the end user needs it to make their role more efficient. A user story consists of four parts:
- Title — name of the user story and how it is identified
- Persona — the user role, playing the part in the user story (i.e., the end user)
- Description — what the user needs and the reason they need it
- Acceptance criteria (AC)— the conditions the user story needs to be successful
The acceptance criteria consists of actionable steps, tasks that should be completed prior to the user story functionality, and completion of the functionality in the acceptance criteria itself.
The AC must be thorough, descriptive, and easily understood by anyone on the development team. It could be used to help the business analyst, who is gathering all the requirements from the client and ensuring that everyone knows what they’re working on and in what sequence, and the proper functionality for the requirements needed.
For the configuration specialist, the acceptance criteria informs them on what should be built for the persona to do their job effectively. The developer needs the acceptance criteria to know what level of customization a product or system needs to satisfy the story and, sometimes, needs to work alongside the configuration expert to do so.
Lastly, the project manager could also benefit from having clear acceptance criteria. They need to make sure that everyone has what they need to do their jobs effectively, but also ensure that everyone has a centralized way of communicating to get the project across the finish line.
Types of acceptance criteria and how to use them
There are two types of acceptance criteria: scenario-oriented and rule-oriented.
- Scenario-oriented uses a Given/When/Then (GWT) format — given some prediction, when I do some action, then I get some result. It helps testers know the start and end of testing for a particular feature. So you have the given, which is the beginning state of the scenario; the when, which is the action that the user makes; and the then, which is the outcome of the action in the when statement.
- Rule-oriented can be for situations where the GWT would be less effective. It’s used for describing system-level functionality. This method could be used for developers to get more critical details. They’re usually documented in steps and displayed as bullet points.
There are some considerations for how acceptance criteria should be written, but I’ve found that using both methods together can be highly effective. Let’s use the pie analogy to write the acceptance criteria.
User Story Title: Baking Pies for Guests
Description: As a chef (persona), I need to <bake a pie> so that I can <feed my guests>
Acceptance criteria: Given a chef wants to feed their guests
When the chef has gathered everything that the recipe requires
Then they can bake pies
-User has all recipe ingredients
-User has correct measuring spoons
-1 cup
-1/3 cup
-1 tsp
-User has access to oven
-Preheat oven to 350°F
-User does NOT have any other items on their workstation
The chef has an end goal: to feed their guests. When the chef has gathered the ingredients and tools for the recipe (action), the outcome in the then statement would be the result of that action. It is also important to note the details below the GWT statement. In certain scenarios, it may be useful to add the scenario-based criteria to provide more specific details for clarification. Also, make sure to add functionality that should not happen. This is called a negative scenario.
The go-to checklist
With the many considerations on how to write acceptance criteria, the thought of actually starting may be daunting, but here’s a checklist you can use to help make sure your AC is top-notch:
1. Examine your teams’ needs
How many admins are there on your team? How many developers? Will there be more than one QA person? What’s the size of the project? The length? Are your team members comfortable with the work? Is this a new feature? Do they need more details?
2. Don’t make your AC too specific
This can be tricky. You want to make sure your acceptance criteria isn’t too vague, but also doesn’t provide too much specific information. Remember, you are not solutioning. You are making sure that the value and the steps to get to the solution are recorded in the acceptance criteria.
3. Make sure your AC is measurable
What is needed for the acceptance criteria to be true? How long will this take to build? The acceptance criteria is used to determine how much time is needed to work on the user story. If the acceptance criteria takes too long to complete, it may be useful to break up a user story into several small stories.
4. Talk your process through with your team
If you’re a business analyst, set time aside to meet with your team to align on what type of acceptance criteria works for everyone. If it’s a project where everyone writes their own user stories, have the team agree on a uniform approach together. Remember — just because you’re all on the project now, doesn’t mean it will be this way through the end of the project. Some team members may roll off and new ones might join, but if the structure of the acceptance criteria in your user stories is the team’s consensus, it will be easier for those onboarding to understand the work being done and how.
5. Include negative scenarios
Negative testing helps remind testers to test for scenarios outside of the proper functionality.
6. Revisit the SOW
Other questions and scenarios may come up when writing acceptance criteria. If this occurs, feel free to revisit the scope of work to get more clarification on what is expected. You want to make sure that everything you’re accounting for aligns with what is in scope.
Keeping these steps in mind can help make sure that your acceptance criteria is clear and concise, ultimately creating a space for your teams to be successful.
Slalom is a global consulting firm that helps people and organizations dream bigger, move faster, and build better tomorrows for all. Learn more and reach out today.
