BA Team: Product Ownership, Analysis, and Solution Design BA Bi-Weekly Mini-meeting May 19, Acceptance Criteria Defining Success one Story at a Time…

Acceptance Criteria “Acceptance criteria are those criteria that need to be satisfied for a user story’s implementation to be accepted by the customer (or Product Owner). Any specifications defined as a part of the Acceptance Criteria are the minimum acceptable behaviors, so a story must meet all of the stated criteria to “pass” an acceptance test.”

Acceptance Criteria As EIM moves to using user story syntax versus traditional requirements syntax to document requirements, we need to make sure all of the “best practices” elements of a good requirement are accounted for. What this means is that Acceptance Criteria must accompany a user story to create a complete picture for the development and test teams. When… Then… Defined Meaningful Measurable Adequate Actionable Requirement User Story Acceptance Criteria

User Story Construction: Acceptance Criteria *Ron Jeffries Scenario 1: Selecting Toppings for Whole Pizza Given: The user has selected a pizza size in the Begin Order window and clicked Next When the user selects (clicks box next to) one of the following items from the toppings list: SausageAnchoviesCanadian Bacon PepperoniPineappleGreen Peppers OnionsBlack OlivesTomatoes Then: 1 – the check box displays as “checked” 2 – the flash pizza image displays the select topping on the entire pizza within 1 second 3 – the whole pizza check box in the adjacent column is selected by default Scenario 2: Selecting Toppings for ½ Pizza Given: The user has already selected one or many toppings for the whole pizza When the user clicks the ½ pizza check box in the column adjacent to the select topping Then: Multiple Topping Selection Scenario: Given: When:, and: Then: And: Or: Basic Construction To reach the completeness level of a traditional requirement, both the User Story (description) and the Acceptance Criteria must be complete. It is fine to create initial stories without this criteria, but the criteria (details) must be in place before customer approval of a story and sprint planning - to ensure that the implementation details are clear.

Acceptance Criteria Allows success to be measured and recognized Enables the creation of Test Plans Enables accurate LOE estimates during sprint planning Removes ambiguity inherent in User Stories Allows developers to build to (and only to) the appropriate scope Things to Consider when writing Acceptance Criteria Acceptance Criteria provides objectivity to user stories, which are by nature “place holders” for conversations, and rarely contain enough information to provide a solid foundation for sprint planning and project execution. Good acceptance criteria:

Qualities of Good Acceptance Criteria While a key goal of Acceptance Criteria is to put definition around a user story and clarify implementation expectations, there is a fine line between writing acceptance criteria in a way that sets up a project for “success” (acceptance tests pass) vs acceptance criteria written in a way that inadvertently hinders success by putting too strict of boundaries and definition around requirements. Balancing measurability with flexibility The skill in writing good criteria lies in the ability to balance the need to provide: Enough detail to prevent confusion and ambiguity so the user gets the functionality they need (what), but Not so much detail (or the wrong kind of detail) that there is no flexibility that would allow for alternate implementations (how)! Details Measures Boundaries Flexibility Interpretation

Qualities of Good Acceptance Criteria Criteria should be written, where possible*, to state an intent rather than unnecessarily detailed and inflexible system behavior. Criteria should be independent of implementation technology wherever possible* (ideally the phrasing would be the same regardless what technology is being used to implement the feature). Criteria is relatively high level, reflecting the user experience rather than details of the system presentation (not every detail needs to be in writing) Because agile allows easy changes to implementation details: * Remember, these are best practice guidelines to consider – not non- negotiable rules. There may be times when acceptance criteria can and should include UI or more system-centric details – just make sure if those details are included it is because they are important to the client or because we have committed to certain implementation or “how” details already!

Qualities of Good Acceptance Criteria Criteria should be written, where possible, to state an intent rather than an unnecessarily detailed and inflexible system behavior. Because being agile allows easy changes to things like UI details: …the user can choose a case type. …the user can select a case type from a drop-down list. Rather than use language like… Try language like… When the user clicks the save button, then the information on the page is submitted to the xyz database. When the user saves a form page, then the information on the page is permanently stored in the system. or

Qualities of Good Acceptance Criteria Criteria should be independent of implementation technology wherever possible. Because being agile allows easy changes to things like UI details: When the user refreshes the page, then the information on the page is updated to reflect information no older than 10 minutes. When the user clicks refresh on the web browser, then the system refreshes the web page using the xyz service call via the “10-minute SOA Architecture” layer. Rather than use language like… Try language like…

Qualities of Good Acceptance Criteria Criteria is relatively high level, reflecting the user experience rather than details of the system presentation. Because being agile allows easy changes to things like UI details: When the user selects a region when creating a new user, then the system limits the other user options to be region-specific. When the user chooses a region from the multi-selection “Region” box in the “Create New User” window, then the state dropdown, “Manager” list box and “Office Code” dropdown options all become region-specific based on the incurrence of the Region Business Rules. Rather than use language like… Try language like…

Qualities of Good Acceptance Criteria Key points to remember… Summary Acceptance criteria is critical as it enables the team to manage scope, determine “doneness”, and objectively test a solution. Acceptance criteria should be written in a way that makes each story (requirement) measurable and understandable. Acceptance criteria should be written in a way that doesn’t unnecessarily limit flexibility in implementation (how) options.