Design for variance reasons

[LindsayMacfarlane]

Description:

Design for how we can implement reasons for variances in A&R.

A&R will share the list of common variance options. Context: This list will be matched up with list used in staff advisory portal for consistency

Needs:

• pre-determined list of reasons for variances they can select (dev preference: everything they can possibly think of, IN ADDITION to the 10 main things) Sub categories too. SEE HERE FOR LIST: https://github.com/bcgov/bcparks-ar-admin/issues/393#issuecomment-2418083944
• including one where they can write their own
• can select multiple
• good for metrics
• compliance for A&R to have the variance
• trying to reduce friction for them to comply

Acceptance Criteria:

• Designs that capture the above needs
• implementation ticket (#393) has been updated with AC according to designs

Development Checklist:

• [ ] ...
• [ ] ...
• [ ] ...

Dependencies

• Blocked by
• Blocking #393

Relevant documentation as reference

Definition of Ready

• [ ] Acceptance criteria are included
• [ ] Wireframes are included (if applicable)
• [ ] Design / Solution is accepted by Product Owner (if applicable)
• [ ] Dependencies are identified (technical, business, regulatory/policy)
• [ ] Story has been estimated (under 13 pts)

Definition of Done

• In progress:
  • [ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
  • [ ] UI meets accessibility requirements
  • [ ] Unit tests are written
  • [ ] Work is traceable in GitHub
  • [ ] PR linked to ticket number
  • [ ] If needed/required - Dev adds flag/label to highlight any migration steps necessary prior to PROD deployment
• Code review:
  • [ ] Code is peer reviewed and has passed CI/CD tests
• QA:
  • [ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
  • [ ] Code is potentially shippable to the production environment
  • [ ] Functional features have been tested and passed by QA
  • [ ] UI components tested by designer
  • [ ] Code is deployed to PROD when moved to 'done' column (unless requested otherwise by PO)
• PO Review:
  • [ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
  • [ ] Reviewed and approved by Product Owner

Notes:

[LindsayMacfarlane]

Standardized variances - working copy - https://bcgov.sharepoint.com/:x:/r/teams/031072/Shared%20Documents/Attendance%20and%20Revenue/Variance/Standardised%20Variances-%20working%20copy.xlsx?d=w6e4eda1261f1465fb8036c7d96ff7fad&csf=1&web=1&e=HMUkq2