Concourse & Jira DC Portal

Within work items in Jira add a field that shows the stage it's assigned to.

Right now, we can see the parent of the work item, but not the Stage which is often the grandparent.

12/9/25 draft Feature update to discuss with @Nachiket Bal based on Conversation with Jake, Missy, Nish re: updates to this Idea:

✅ Updated Feature Name:

“Enable Smart Filtering of Jira Work Items by Stage and Level”

✨ Put Simply:

Users want to filter Jira work items by stage and hierarchy level (L2–L6) without breaking the structure, enabling both complex and simple teams to see only the items that matter.

🔍 Problem Statement:

Right now, users cannot filter work items in Jira by delivery stage or level in a way that maintains the parent-child structure. This makes it difficult to customize views, especially for those managing hundreds of deliverables or trying to create simplified lists.

💡 Why This Matters:

This gap impacts a wide range of teams — from those managing SAP-scale engagements to those handling 15-item scopes. Without smart filtering, users either lose structural integrity when applying filters or are forced into cluttered, inefficient views. This leads to frustration, manual workarounds, and missed delivery visibility.

📦 Solution Scope:

This feature will:

• Automatically tag each work item deployed to Jira with:

  • Its delivery stage (e.g., Discover, Innovate, Release, etc.)

  • Its hierarchy level (L2–L6 or equivalent)

• Ensure that this metadata:

  • Persists across Structure and List views in Jira

  • Does not interfere with parent-child linkages

• Enable filtering by any single level, stage, or combinations (e.g., "Show only L3 items in the Release stage")

• Support different filtering needs (e.g., SAP teams want L3 filtered; others want a flat deliverables view)

• Serve as the foundation for future metadata tagging used in advanced filtering logic

👥 Personas:

• Delivery Leads & Engagement Managers – Need to quickly isolate relevant work items across large delivery programs.

• Implementation Consultants – Want to quickly find their assigned tasks by stage or level.

• Team Members on Smaller Projects – Prefer a flat list of deliverables without unneeded scaffolding.

🌍 Reach:

• Affects the majority of engagements pushing work to Jira via Concourse 2.0.

• Especially impactful for SAP, Oracle, and other delivery templates with L2–L6 complexity.

• Supports users using Jira Structure and List View plugins.

🧩 Business Rules & Requirements:

• Field values must be automatically populated at deployment (no manual entry).

• Jira filters should:

  • Maintain parent-child structure

  • Work across all hierarchy levels

• Concourse templates should define the tagging logic (i.e., what stage/level is applied)

• Support multiple fields (stage, level) in filtering combinations

• Must be compatible with Jira filtering capabilities (Structure, List, etc.)

🔄 Rollout Strategy:

• Feature Flag in LaunchDarkly to enable template-specific rollout (e.g., SAP templates first).

• Collaborate with Nachiket’s team to validate technical field mapping in Concourse-to-Jira integration.

• Confirm behavior across various Jira views (Structure, List).

✅ Readiness Checklist

👕 T-Shirt Size:

Medium (M)
Field tagging logic already exists in legacy system (Concourse 1.0); work involves restoring tagging and ensuring correct mappings and filters apply in Jira views.

🛠️ Draft Story (Backend Focus)

Title: Auto-Tag Work Items with Stage and Level for Jira Filtering

Description:
As a Concourse user
I want Jira work items to be tagged with both their delivery stage and hierarchy level
So that I can filter them accurately in Jira without breaking the structure.

Acceptance Criteria:

1. Stage Field Automatically Populated

   • Given a work item is deployed from Concourse

   • When the item is created in Jira

   • Then the "Stage" field is populated based on its position in the delivery flow (e.g., Discover)

2. Level Field Automatically Populated

   • Given a work item is deployed from Concourse

   • When the item is created in Jira

   • Then a "Level" field is populated with its depth (e.g., L2, L3, etc.)

3. Fields Support Jira Filtering

   • Given these tags exist

   • When a user applies filters in Jira Structure or List view

   • Then the filtering works without disrupting parent-child relationships

4. Supports Combinations

   • Given a user wants to filter by multiple conditions

   • When they select Stage = Release and Level = L3

   • Then the correct subset of items is shown

5. Fails Gracefully

   • Given a work item lacks tagging due to deployment error

   • When viewed in Jira

   • Then Stage and Level default to "None" and filtering is unaffected

Story Points: 5
Requires backend field mapping, validation in Jira filtering tools, and deployment test coverage.

Work Type: Back-End (BE)

📣 Release Note (User-Facing)

You can now filter Jira work items by both stage and level — like "Release-phase L3 items" — without breaking their structure. This makes it easier than ever to manage complex programs or focus in on just what you need.

Let me know if you'd like:

• A split FE story for UI interactions in Concourse

• A usability test script for validating this new filtering flexibility

• Or a follow-up feature to support more metadata fields in the future (like region, team, etc.)