Variance note reason standardization

[LindsayMacfarlane]

Description:

As an admin, I want to be able to quickly select a common variance reason in order to speed up my data entry process.

[Description of the ticket]

Acceptance Criteria:

Given I am an admin or Park Operator When I go to enter my variance reasons Then I see a standardized list of reasons that I can select from

Development Checklist:

• [ ] Get list of variance reasons
• [ ] Determine if radio button or drop down is most appropriate approach
• [ ] ...

Dependencies

• Blocked by
• Blocking

Wireframe(s):

Workflows:

Definition of Ready (Note: If any of these points are not applicable, mark N/A)

• [ ] User story is included
• [ ] User role and type are identified
• [ ] Acceptance criteria are included
• [ ] Wireframes are included
• [ ] Design / Solution is accepted by Product Owner
• [ ] 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:

• We have some standard reasons for variances, many of which will also line up with "event type" from the staff advisory portal, like wildfire closure, trail closure, weather events (flood, snow warning etc), that could be selected from a list rather than typed out by the person entering data. This will speed up entering variances, make it more likely the PO fills out the variance field, and make it easier to analyze variances/ filter by variance type.

[LindsayMacfarlane]

October 11, 2024 prioritization session:

• A&R team highlighted as a priority
• Standardizing common reasons for variances would allow the team to filter and report out and improve data entry speed
• To do: get a list of from A&R team of common list of reasons.

PO question: would we need an 'other' catergory and allow people to add in additional variance reasons?