Downloaded 180 times
Uploaded byDataArt
Acceptance criteria
Acceptance criteria define specific, measurable conditions that must be met for a user story or feature to be accepted. They help ensure stakeholders have a shared understanding of what needs to be delivered before development begins. Good acceptance criteria are independent of implementation, written from the user perspective, and use a format like Given, When, Then. They describe what is expected rather than how it will be implemented. Acceptance criteria should be defined before development starts to guide testing and determine when a user story is complete.
More Related Content
Similar to Acceptance criteria
Acceptance criteria
- 1. Acceptance criteria vs. Functionalrequirements by Anna Dąbrowska
- 2. 1. Who? 2. What? 3.Why? User stories Never go into development without the story or narrative having: • priority • story or narrative (depending on complexity) • acceptance criteria • knowing what the end to end test scenario is /are • sign off from the customer for all of the above • an estimate from iteration based on all of the above
- 3. What are AcceptanceCriteria? Acceptance Criteria are a set of statements, each with a clear pass/fail result, that can be measured and specify both functional and non- functional requirements. Acceptance Criteria are the conditions that a software product must satisfy to be accepted by a user, customer, or in the case of system level functionality, the consuming system.
- 4. Why to write? •Define the boundaries for a user story/feature • Help the product owner answer what she needs in order for this feature to provide value (typically these are the minimum functional requirements) • Help the team gain a shared understanding of the story/feature (BEFORE development has started) • Help developers and testers to derive tests • Help developers know when to stop adding more functionality to a story *Icons are created by Nathanael Coyne (@nathanaelb).
- 5. How to write? Goodacceptance criteria: • State an intent not a solution (e.g. “The user can choose an account” rather than “The user can select the account from a drop-down”) • Are independent of implementation • Are relatively high level (not every detail needs to be in writing) • Are SMART • Have observable result • Include actor/actions/environment/conditions/context • Are written from user perspective
- 6. How not towrite? Watch out for • Ambiguous language • Subjective/Judgemental language (Better, Good, Allowable) • Generalisations (All the time, Never, Everyone, Always) • Observed behaviour that is not directly related to the story currently under consideration
- 7. Methods to write 1.Scenario style approach • Happy Path • Alternative Path • Bad Path 2. BDD style acceptance criteria • Given <a condition> • When <an event occurs> • Then <expect this outcome>
- 8. When to write? !Avoid is writing acceptance criteria after development has started
- 9. WHAT is expected, andnot HOW the functionality will be implemented. What. Not How Functional requirements Acceptance criteria Requirements are what you're supposed to do in terms of given story. Acceptance Criteria are the agreed upon measures to prove you've done. Acceptance Criteria are defined as conditions that a User Story must satisfy to be accepted by a user, customer or other stakeholder.
- 10. Example. Try towrite Functional requirements 1. Site language corresponds to chosen one 2. Language can be changed 3. Default language icon appears in top right corner 4. English is a default language 5. Dropdown with list of languages appears by clicking on language flag in right top corner 6. User can select language by clicking on corresponding one in drop-down menu 7. Site content changes to selected language after user has clicked on its name/icon in switching drop-down 8. List of languages and translations are grabbed from admin panel As a user I want to switch application language so that I understand app content
- 11. Example. Try towrite 1. User can change site language 2. Site content corresponds to selected language 3.Translation is correct and doesn’t contain critical mistakes 4. Translated content doesn't break any specific layout 5. No bugs of high and normal priority related to switching languages remain open Acceptance criteria As a user I want to switch application language so that I understand app content
- 12.
Editor's Notes
- #8 ATM example of withdrawing cash: What is the user story? As an account holder I would like to withdraw cash from an ATM so that I have money to spend. Happy Path For a favourable outcome what business conditions need to be met? Account Holder enters valid pin Account Holder has a balance matching or exceeding requested amount ATM has cash matching or exceeding requested amount So what should happen when the Account Holder tries to withdraw cash? ATM dispenses requested cash immediately Account Holder's balance is reduced ATM cash balance is reduced We've just described the happy path for the ATM withdrawal story. The business conditions were identified, and the acceptance criteria we can use to validate that the solution meets the customer's needs was listed. Alternate path The path with some deviations that allows users to reach the desired outcome ATM example continued: What if any of the business conditions identified in the previous exapmles were not true? What if the Account Holder enters an amount greater than his balance? Indicate that there are insufficient funds in his account Can we stop here? Can we provide some functionality that will allow the user to still reach his goal? Display a message and Provide option to specify a lesser amount We can still satisfy the goal even though the path is not direct. This is what some people call an "Alternate Path". This is still acceptable as it allows user to reach his goal. Bad Path That path that does not lead to the desired outcome ATM example continued: What else can happen? Can something go totally wrong? For example, maybe you cannot connect to the Bank Account Holder's card has expired Unexpected error in the system. Buffer overflow, Null Pointer.. We try our best to prevent these from occurring by writing more test, adding more functionality that caters to these situations (adding resilience). And provide a graceful recovery from unexpected outcomes - error messages and return to start page.
- #10 Acceptance criteria do not replace the conversation they are one of the results of the conversation