From the course: Agile Requirements Foundations

Acceptance criteria

From the course: Agile Requirements Foundations

Acceptance criteria

“

- So, how do we know the user story will meet all the user's expectations? And where do all the details go for this user story? Teams define this with acceptance criteria which are all the conditions that tell us when the user story is working as intended and satisfying the customer. Although the team may define it together, the BA plays the main role in generating and documenting these acceptance criteria conversations. These conditions are typically created and owned by the product owner, with the BA doing much of the heavy lifting, and they're attached to a user story. Acceptance criteria help the team define what success looks like from a user perspective. Acceptance criteria are typically a list of statements that have a clear result. Think of them like statements you could build a test to, to test the products. They might contain scenarios, rules and logic that create a specific outcome for a user, or there might be non-functional requirements like security, performance, expected volumes, response time, and thresholds of performance. I like to keep acceptance criteria for each story to up to 10 statements, and link, or attach models that provide further logic or context to the story. Let's look at an example from our online coffee store payments case study. As a customer, I'd like to select a payment type from my profile so I don't need to re-enter my payment information. Now that's the user story. The acceptance criteria for this story is typically a bulleted list, and may look something like this. When I select to checkout, my stored payment methods are displayed to me. I can select which payment method I want to use for the purchase. When I select the method I want to use, the details are populated in the fields. I'm asked to confirm the details. The system validates the details are still valid and asks me to correct if any are not valid. Updated details are stored in my profile. In this list of acceptance criteria, some of the statements could be user stories of their own. If we need to slice or split the story even further, we could use some of these criteria. Notice that every statement is from a user point of view and how they would describe success. The statements are not tasks that the technical team needs to do, nor detailed technical design descriptions. The list focuses on outcomes that a user would be able to pass/fail without any working technical knowledge. Acceptance criteria is not meant to be an all inclusive list of every little detail, but it gives the team enough information to remember, discuss, and test the story. Great acceptance criteria can make all the difference in stories getting completed in a way that truly satisfies the users.

Contents