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
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
* 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
(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)