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
...
All defined requirements and acceptance criteria are addressed.
A pull request is created and:
is reviewed and approved by 2 default reviewers
has a passing pipeline build
meets unit and integration testing requirements
Tested and marked passed by the QA team on the QA environment.
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.
The individual who wrote the code for the ticket should not be the individual owning the ticket during the QA process.
Local testing does not replace testing on the QA environment
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
Any work involving UI/UX should be PM reviewed by the UX member on the team as well
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.
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 a 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”.)
PM moves the ticket to “Done” column on the sprint board and marks it “Ready for Release”
...
If a bug is identified as a hot fix, this is immediately pulled into the sprint and assigned a developer. Their current sprint commitment should be re-assigned or pulled out of the sprint as necessary.
A bug identified during staging verification is considered a release bug. When this occurs, there are 2 options for moving forward:
The developer who did the original work on the ticket drops their current sprint priority and works to apply a fix for the bug to be included in the current planned release.
The PM may decide that releasing the bug in the current state is acceptable. If this is the case, a bug ticket is created to describe the issue and staging verification continues as normal.
The QA member who found the bug should leave a detailed comment on the ticket outlining the bug found and the plan agreed upon by the team.
Follow the processes listed here for branching, merging, and deploying hot fixes and release bugs: SuperNurse Release Process
Pull Request Process and Best Practices
...