I developed the following Acceptance Criteria Template when defining user stories as part of defining software requirements and specifications. It can be copy-pasted into a product development tool like or that supports markdown to create bold headers and a bulleted list beneath each header. This should be entered in the Acceptance Criteria field of the issue-tracking tool (built-in to Azure DevOps but may require a custom field in JIRA), while the Description field should be reserved for a short introductory narrative, possibly with the structure “As a [end user]”, I want to [take an action], so that I can [receive a benefit].”. If you use statements, those would be listed in the *BEHAVIOR* section. There is a that shows what Acceptance Criteria for a user story might look like with links out to assets such as designs, a full list of analytics events/properties, etc. For more information on how Acceptance Criteria fit into the broader context of software requirements and specifications, please see .
* How to get to this screen (passive or active from user)?
* What user must have in order to enable functionality? (i.e., pre-conditions)
(If using Gherkin Given-When-Then statements, those go here)
* What happens when you get to this screen (passive or active from user)?
* How do things on the screen works?
* How do you get out of this screen?
* What happens when you exit this screen? (i.e., post-conditions)
* What are the unanswered questions?
* What kind of input do we want the user to give us?
* What are the limitations? (e.g., character length, adherence to formats)
* What is the empty/default state?
* What are the error states?
* Where is the referenced designs? (e.g., links to appropriate mockup / wireframe)
* What does the text say? (should be copy / paste-able for developer)
* Alternatively, state "use copy from designs"
*OUT OF SCOPE*
* What functionality is NOT included in this story? (e.g. things that are manual today that will be automated in the future)
* What are the expectations around offline support? (i.e., should any data or functionality be stored locally)
* What events and properties should be recorded for analytics purposes?
Users will land on the account confirmation page after following the CTA in the email that is generated for new users and users with unconfirmed accounts in SER-55 Precondition: The user must have requested an appointment and have had an initial account set up on the back-end. Account state is "Unconfirmed" at this point. If the user accesses this link but there is already a confirmed account (and set password) associated with the email address, they should instead land on the sign in page (SER-57)
The user will see static copy followed be a field with their email address pre-populated (email address will not be editable at this point) Below their email address the user should see one field - "Enter password" The password should not be visible while inputting, however, the user should have the ability to select "Show" to see the actual characters that have been typed Confirm Password CTA: After inputting a password successfully, the user can select the "Confirm Password" CTA and should be brought back to the home page in a logged in state (more details on landing page in SER-66) After successfully setting their password, the account is now in "confirmed" status If the user exits the screen before confirming their email address there will be no changes to the back-end. They will have an unconfirmed account and will need to re-access the link from the email they received.
Password requirements should be based on the 'Good' level of Auth0: at least 8 characters including at least 3 of the following 4 types of characters: a lower-case letter, an upper-case letter, a number, a special character (such as !@#$%^&*)
Error state if the user selects "Confirm Account" and the password does not match character length and character type requirements
Desktop: https://zpl.io/anmLypk Tablet: https://zpl.io/2vlP5X5 Mobile: https://zpl.io/anme6GO
(see designs for latest copy)
OUT OF SCOPE
The user is not able to edit their email address. They will be able to edit it in future sprints within the edit account functionality (not during the email confirmation step)
please reference (note: you should create a copy of this spreadsheet and fill it out if using a tool like or to track analytics) "Confirm Account" CTA event: triggered when a user successfully sets their password and confirms their account
Coda is the doc platform that brings words, data, & teams together. Join the more than 25,000 teams using Coda and !