Super Nurse Practices and Protocols

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. When a ticket is created, the default Status is “Backlog” & the Backlog Status is “To Be Refined.”

2. As a part of the refinement process:

   1. When the ticket clearly outlines the requirement of the feature/developer task and has all required supplementary documentation (i.e. screen shots of mockups and links to Figma), the Status should be changed to “Ready for Development” and the Backlog Status should be changed to “Ready.”

   2. During the Refinement process if further information is needed from the PM/UX before work can begin, the ticket will not be pointed, the Status should be changed to “PO Blocked” and the Backlog Status to “Needs Detail.”

      1. This ticket should remain in the team’s Backlog until it’s actually ready for work and will be pointed appropriately.

Definition of Dev Done (Sprint Complete, Not Released)

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 a ticket it will not show in the Backlog
         (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”

Refinements

1. During Refinement, we want to start breaking tickets up into smaller increments to demonstrate to Leadership how much our teams are working on, and how many increments of done we are completing

   1. If an original ticket is created with all requirements, but there are multiple pieces to complete before the ticket can be considered done, then we’ll spend time during Refinement breaking it out as needed

   2. Each ticket will be pointed separately to reflect its individual level of effort

   3. This process shows that we are progressing toward the end goal and completing relevant work, where having multiple requirements in one ticket would prevent us from considering it done (even if half of the functionality is complete)

2. Story points are based on the complexity of the ticket and should not be considered “time to complete” the ticket.

3. Story point voting should be anonymous as people are voting – votes should be shown at once, to avoid swaying effort estimation (Poker Planner in channel now).

4. If there is a discrepancy between effort estimation from voting, the team should discuss and either revote or agree on an effort level.

5. If a ticket needs more detail or clarity from the PM team, change the status to “PO Blocked” and the backlog status to “Needs Detail”

Sprint Planning

1. Rolling velocity from the prior three sprints is calculated and added to the Capacity Planning spreadsheet. This is the average of the number of points completed by the team across the three most recent sprints.

2. Developers and Test Engineers add their availability for each day of the upcoming sprint to the Capacity Planning spreadsheet. These numbers are used to calculate a team capacity percentage.

3. The team should determine remaining effort in the current sprint: how many points of remaining tickets will be rolling over? (i.e. a ticket originally assigned as 8 points of effort is rolling over and is in testing, the team determines that there are 2 remaining points of effort)

4. When pulling in tickets for the new sprint

   1. The target velocity is the Team Capacity percentage of the rolling velocity, minus the remaining points rolling over from the prior sprint.

   2. Once the target velocity has been reached, each developer should identify which tickets they are likely to work on over the course of the sprint. If they do not feel like they have enough work for the 2 week sprint, they should work with the PM to identify another ticket(s) to add to the sprint.

   3. We want to avoid over-promising & under-delivering

   4. We don’t want to pull in so many tickets that we end up rolling tickets over from Sprint to Sprint

5. Typically, only tickets that are marked “Ready for Development” with a Backlog Status of “Ready” and have sprint points should be pulled into a sprint.

   1. If a ticket that has not yet been refined, or is marked as “PO Blocked” with a Backlog Status of “Needs Detail” needs to be pulled in per PM, the ticket should be refined within the Sprint Planning meeting or ASAP.

Requirement Gap Documentation

Sprint Workflow

• If a developer needs more work mid-way through a sprint

  • If there is work in the To Do column that has not yet been started, the dev needing work can reach out to the PM and the dev assigned to the ticket to see if they can start that work

  • If there is no work in the To Do column, the developer can work with the PM and DM to pull in a ticket from the top of the backlog (most priority ticket that is relevant to the developer) or reach out to the other team members to see if they need help with anything in progress

  • If the ticket is too large of an effort to pull in and complete before the sprint is complete – the ticket will still be pulled in to the current sprint, knowing that a portion of it will roll over

• If the QA team finds a bug or missed AC during sprint testing

  • A note about the kickback should be left by the QA member testing the ticket in the comment section

  • The ticket should be moved back to “In Progress” and re-assigned to the developer

  • If the bug is found near the end of the sprint, near the code freeze prior to merging code into the stable branch, and discussion should be had with the PM/DM/Dev/Release Owner about the plan to correct the bug as a priority prior to the code freeze.

    • If the bug is acceptable to release to production, consider creating a bug ticket to track the issue and move the original ticket through the sprint as normal. (NOTE: In Jira, the Blue Dot Product Team is known as “Kandor”.)

  • Ticket ownership

    • Appropriately move stories on the Sprint board when there is an action on the ticket

    • Software Engineer owns ticket until Ready for Testing

      • This means that when a PR is approved and merged, the developer should confirm the deployment was successful, and then move the ticket to Ready for Testing

    • Test Engineer owns ticket until PM review

    • PM owns ticket to Ready for Release

Hot Fixes and Release Bugs

• 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: Nurse Job Board Release Process

Pull Request Process and Best Practices

• Before creating a PR

  • Perform a self-review of your code

  • Confirm your code follows the style guidelines of the project

  • Add comments in hard-to-understand areas of your code

  • Update any relevant documentation in Confluence or the Project ReadMe related to your code changes

  • Confirm there are no new warnings or deprecations generated by your code

  • All necessary unit/integration tests have been added to reflect new functionality and code coverage requirements

  • All unit and integration tests pass locally with new code changes

• When creating a PR, make notes of any testing you completed locally to confirm your fix and any helpful notes for the individual reviewing your code.

  • If screenshots would be helpful to illustrate UX/UI changes, please include those on the PR as well.

• If a PR is especially large (we would like to avoid large PRs if possible), consider meeting with the default repo approvers to walk them through your code as a group to expedite the review process.

• After submitting a PR, review the testing instructions added by QA and confirm they accurately cover the AC