Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

ALYSSA AND ASHLEY TO MAKE UPDATES SOON. PLEASE REVIEW NOTES/UPDATES ON THE Q3 2023 Quarterly Planning Topics & Jira Workflow Issues/Suggestions PAGES FOR NOW.

Definition of Ready for Development

...

  1. All defined requirements and acceptance criteria are addressed.

  2. A pull request is created and:

    1. is reviewed and approved by 2 default reviewers

    2. has a passing pipeline build

      1. meets unit and integration testing requirements

  3. Tested and marked passed by the QA team on the QA environment.

    1. Any code that reflects changes to the FE visually, changes functionality, or updates underlying site infrastructure should be tested by QA on the QA environment.

    2. The individual who wrote the code for the ticket should not be the individual owning the ticket during the QA process.

    3. Local testing does not replace testing on the QA environment

  4. PM reviews the ticket on the QA environment to confirm that all requirements and AC are addressed and look/function as expected for product requirements

    1. Any work involving UI/UX should be PM reviewed by the UX member on the team as well

      1. I.e. A ticket involved creating a form element on the page – UX should review the form as it compares to the provided mockups and confirm that specs for the design are represented as expected.

      2. If the work does not meet UX requirements, UX and PM will discuss if the changes need to be made prior to the code release, or if a bug ticket should be made. Reminder: If the Product Team is not added to the ticket it will not show in the Backlog - this needs to be default for everyone going forward. (NOTE: In Jira, the Blue Dot Product Team is known as “Kandor”.)

  5. PM moves the ticket to “Done” column on the sprint board and marks it “Ready for Release”

...