Concourse Feedback

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:

Feature Name: Hierarchical Stage Field Mapping & Sync to Jira for Work Item Reporting

Put Simply

Automatically populate the "Stage" field (and potentially "Substage" and "Activity") on every work item — including deliverables, tasks, and subtasks — to simplify Jira filtering, reporting, and grouping, based on hierarchy in Concourse.

Problem Statement

Teams (e.g., SAP, Oracle) rely on slicing and dicing data by Stage for reporting and operational reviews. Currently, only Stage-level items carry this metadata. As a result, users lose visibility into the Stage context when working in Jira at the deliverable or task level. Though the mapping exists in Concourse, it's unclear whether that logic transfers cleanly to Jira — and manual tagging is not scalable.

Updated Scope and Enhancements

✅ Add the Stage field to all work item types in Concourse and Jira (L4–L6)
✅ Pre-populate Stage based on structure/hierarchy (auto-inherited from parent Stage)
✅ Sync Stage into Jira Cloud issues to enable filters and reports
✅ Ensure mapping logic supports one-to-many relationships when children span multiple parent levels
✅ Evaluate adding Substage and Activity as future extensions or bundled fields, pending confirmation
✅ Allow practice-specific value customization via Jira (and eventually via a self-service portal)
✅ Mark this as a higher priority than files work due to its data value and reporting relevance

🎯 Updated User Stories & Acceptance Criteria

User Story 1: Auto-Inherit Stage Field from Parent in Structure

As a Concourse user
I want the Stage field to be inherited by all work item types from their parent
So that I can avoid repetitive manual input and maintain consistent metadata across all levels

Acceptance Criteria:

1. Given I create a work item (deliverable, task, or subtask) under a Stage,
   When the item is saved,
   Then the Stage field should auto-fill with the parent Stage’s value.

2. Given a work item is moved to a new Stage parent,
   When saved,
   Then its Stage value should be updated accordingly unless overridden.

3. Given a work item has no Stage (e.g., top-level work item added manually),
   When the structure is refreshed,
   Then the system should attempt to infer and backfill the Stage based on hierarchy.

User Story 2: Sync Stage Field into Jira for All Work Item Types

As a Jira user
I want every synced issue (regardless of type) to have a Stage field
So that I can group and filter issues by Stage for reporting

Acceptance Criteria:

1. Given a work item is synced from Concourse to Jira,
   When the sync completes,
   Then the Jira issue contains a custom field labeled “Stage” with the correct value.

2. Given I view a Jira project,
   When I filter or build dashboards,
   Then I can include/exclude issues based on Stage.

User Story 3: Confirm and Implement Mapping Logic for Jira

As a developer or product analyst
I want to confirm how field inheritance is handled from Concourse to Jira
So that we don’t lose context or apply values incorrectly

Acceptance Criteria:

1. Given a mapping already exists in Concourse,
   When syncing to Jira,
   Then the field mapping should preserve the hierarchy-derived Stage field.

2. Given we find discrepancies in mapping behavior,
   Then we must adjust the sync logic to ensure alignment with parent values.

User Story 4: Evaluate and Optionally Add Substage and Activity Fields

As a practice lead or analyst
I want the option to track and report on Substage and Activity (L2, L3)
So that I can support more granular workflows if needed

Acceptance Criteria:

1. Given we confirm system capability,
   When Substage and Activity are added to work items,
   Then they must follow the same inheritance logic as Stage.

2. Given we decide to phase these in later,
   Then the current implementation should not block future field additions.

User Story 5: Customize Stage, Substage, Activity Field Values

As an admin
I want to manage and expand allowed values for Stage, Substage, and Activity
So that they can reflect the evolving structure of different practices

Acceptance Criteria:

1. Given a team requests new values,
   When a Jira ticket is submitted,
   Then the new value should be added to the selectable list.

2. Given self-service portal functionality is developed,
   Then users should eventually be able to manage these values without admin intervention.

🧠 Story Point Estimates

🔧 Work Type

• FE: Work item metadata view, field dropdown, group by Stage

• BE: Inheritance logic, field mapping, Jira sync

• Config/Admin: Field value management, future self-service hook

🔍 Summary

To support clean reporting and reduce friction, this feature ensures that Stage is present and accurate across all work items synced from Concourse to Jira. It aligns structure with metadata, lays the foundation for future Substage/Activity fields, and makes filtering easier for practices with complex project setups.

✅ Why This Feature?

✅ Unblocks reporting needs for SAP, Oracle, and similar practices
✅ Prevents manual tagging across deliverables and subtasks
✅ Syncs structure-driven hierarchy directly into Jira
✅ Supports scalable field extensions without disrupting current work
✅ Now prioritized above file work based on value for analytics and workflow clarity

📣 Release Note (User-Facing)

You’re now able to see the correct “Stage” value on every work item — whether it’s a deliverable, task, or subtask — both in Concourse and Jira. This means faster reporting, smarter filters, and no more manual tagging. Coming soon: support for Substage and Activity fields!