Turn Your Upgrade Plan into Action: Creating JIRA Tickets

This is the final step of the preparation phase. You have a comprehensive Final Upgrade Plan that details every task required for the upgrade. Now, it's time to translate that plan into a structured, actionable backlog of JIRA tickets for the development team.

A well-defined backlog is the bridge between planning and execution. It provides clarity for developers on what needs to be done, allows for accurate progress tracking, and forms the basis of your sprint planning.

The Process: From Plan to Backlog
What a Good Upgrade Ticket Looks Like
Planning for Parallel Work

The Process: From Plan to Backlog

The core input for this process is the "In Scope Tasks" table from your Final Upgrade Plan. Each row in that table should become one or more tickets in your JIRA backlog.

Head Start: To accelerate this process, a set of template JIRA tickets for specific platform version upgrades can often be provided. Ask your Quantexa contact if a template is available for your upgrade path. You can then import and adjust these tickets to fit your project's specific scope.

Action: Create Epics for Major Stages

Start by creating a master Epic for the entire upgrade (e.g., "Platform Upgrade to v2.8"). Then, if you are performing a multi-hop upgrade, create a sub-Epic for each "hop" (e.g., "Upgrade 2.5 -> 2.6," "Upgrade 2.6 -> 2.7"). This provides a clear hierarchical structure.

Action: Create a Ticket for Each Task

Go through your "In Scope Tasks" table and create a JIRA ticket (e.g., a Story or a Task) for each line item. A good upgrade ticket is specific, actionable, and contains all the necessary context.

What a Good Upgrade Ticket Looks Like

Here are examples of how to structure tickets for different types of upgrade tasks.

Example 1: Ticket for an Automated Migration Step

Title: Run Repository Tool for v2.7 Migration

Description:
As a developer, I need to run the Repository Tool to apply the automated migrations for the v2.6 -> v2.7 upgrade.

Acceptance Criteria:

Repository Tool is executed successfully against the feature/platform-upgrade-v2.8 branch.
All automated migrations from the v2.7 configuration are applied.
The resulting code compiles successfully.
Unit tests pass.
Any failures or manual interventions required are documented in the Issue Tracker.

Example 2: Ticket for a Manual Migration Step

Title: [Manual] Upgrade Document Service Response Handling

Description:
As per the v2.5 migration guide, the response format for the Document Service has changed. We need to manually update our custom UI viewers to handle the new format, which no longer automatically converts Long values to datestrings.

Reference: v2.5 Migration Guide#DocService

Acceptance Criteria:

All custom document viewers are updated to correctly parse and display dates from the new Document Service response.
The UI correctly displays document information without errors.

Example 3: Ticket for a Tech Debt Task

Title: [Tech Debt] Decommission 'Legacy Data Feed'

Description:
As part of the upgrade, we will remove the unused 'Legacy Data Feed' configuration and all associated code from the ETL process.

Reference: Project Backlog Item #1234

Acceptance Criteria:

All configuration files related to the legacy data feed are deleted.
All code that references the legacy data feed is removed.
The main ETL process runs successfully without the legacy code.

Planning for Parallel Work

While many upgrade tasks are sequential, look for opportunities to parallelize work where possible. This is highly dependent on your project's specific architecture. For example, once the core ETL upgrade is complete and tested, the work to upgrade a separate "Scoring" repository and a separate "Apps" repository can often be done in parallel by different developers.

With your backlog created and prioritized, the preparation phase is complete. Your team now has a clear set of tasks to begin the hands-on execution of the upgrade.

Updated 5 months ago