Skip to content
English
Contact us
  • There are no suggestions because the search field is empty.

How-to: Product Review Workflow

Overview

Product Review is intended to be the final quality review by Product for tickets that have completed development and are being prepared for release to our customers.

Workflow

  • Navigate to the Product Review filter in Jira

    • Click on the DETAIL VIEW button in the top right-hand corner of the page to allow for on-page editing

    • “Release Hold” Status Tickets

      • This status is for developments that have been developed by Engineering, tested by Product and QA, but are not ready to be associated with a fix version and released to customers.

      • Some tickets are in this status because they have dependencies on other development tickets. Review the ticket links to confirm whether the tickets are still being blocked from release.

    • “Product Review” Status Tickets

      • This status is for developments that have been developed by Engineering, tested by Product and QA, and are ready to be associated with a fix version and released to customers.

  • Assess the development tickets to get an understanding of what value we are delivering to the customer with the project

  • Assign a Fix Version

    • Fix Versions are assigned based on what application the development is associated with and whether it is associated with a major scheduled release or a patch

      • Major XD Version Example

        • xDispatch_25.5.0.0

      • Patch XD Version Example

        • xDispatch_25.5.0.1

      • CXT Driver Version Example (we plan to change to cxtDriver_x.x.x version soon)

        • nextstopMobile_3.8.0

  • Add Labels (when applicable)

    • Sprint Demo

      • Add when the development has enough value to be demoed to staff

    • Release Priority

      • Add when the development has high value and should be added to the “Highlighted Feature” section of the release dashboard

    • DocumentationNew

      • Add when the development needs to have new documentation created to outline the feature’s functionality or when existing documentation needs to be updated to add in the feature improvement

    • MarketingCOMINGSOON

      • Add when the development has high customer value and our Marketing team needs to be made aware of the new feature or improvement so they can pre-plan for the release blog

    • Patch

      • Add when the development is being included within a customer patch

  • Add Customer

    • Product and Engineering is asked to add any associated Customer information to the ticket in advance, but during the review status, please check for any linked customer tickets that indicate the project was completed at the request of one of our customers

  • Review Release Notes

    • Release notes are publicly displayed to our customers via CXT Software | Product Release Information

      • Keep in mind that public release notes are permanently displayed to anyone that goes to our website, so we must adhere to a strict quality standard

      • Release notes are originally generated by the Product team as tickets are moved from Product Testing (RFT) to QA

    • When needed, update the release notes on the ticket to ensure that we are generating quality information that properly conveys the project’s value to the customer

    • Write [INTERNAL] at the beginning of the release note if the information should not be included in the public release note display

      • Internal release notes could be used for the following:

        • Projects that include multiple tickets and will not be released until the project is complete

        • High-sensitivity issues that do not affect all customers or are being handled immediately in a patch (EX: Temporary rating issues)

    • For public-facing release notes, use the following types of sentence structure examples to create uniformity:

      • Bugs

        • Fixed and issue where [insert issue].

      • Improvements

        • Improved the behavior of [insert behavior] to [explain the customer benefit]

      • User Story

        • Added new [type of functionality] called [insert name of feature, if applicable, to [explain the customer benefit]

  • Add Documentation Notes

    • Add any relevant notes that you feel need to be called out during the documentation process. The team member performing the documentation will be expected to review the ticket, but please indicate anything major that needs to be highlighted to customers within this field.

  • Close Remaining Subtasks

    • The Product Review status is the final check by Product to ensure the development is ready to be released to customers, so there should not be any development or testing-related subtasks left open

      • Leaving open subtasks will prevent the parent ticket from falling off the Kanban boards since it will not be considered done

    • Exception for Documentation

      • Currently Documentation subtasks are still in use and they can remain open for the time being, but please note that we plan to move these out to a workflow outside of the ticket subtasks

      • Documentation subtasks can remain open right now, but all other subtasks must be closed out

  • Update Status to Ready for Release

    • Move the status of the ticket from Product Review to Ready for Release

      • Tickets in Ready for Release will display on the associated engineer’s Kanban board, so they are alerted that they need to merge the code into the fix version that you specified on the ticket