Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 
  • Community
  • Q&A
  • Jira
  • Questions
  • Help Needed: Best Way to Model “Project Phases” and “Project Segments” in Jira Premium

Help Needed: Best Way to Model “Project Phases” and “Project Segments” in Jira Premium

cvanduyn November 14, 2025

Hi everyone,

We’re working on an application development project that includes several layers of work breakdown: phases, project segments, features, epics, stories, tasks, base-level items, and subtasks.

Since we’re on Jira Premium but cannot add a separate Atlassian site, we’re limited to the standard work item hierarchy:

Initiative → Epic → Base Level Item → Sub-task

We’re trying to map our internal model to this hierarchy as cleanly as possible, and we’d appreciate guidance on best practices.

✔️ Our current thinking

  • Project Phase → Initiative
    We believe Initiatives best represent high-level phases and will support governance and top-level reporting.

  • Project Segment → ?
    We need something that represents a major slice of the application — bigger than an Epic but smaller/more specific than an Initiative. We’re considering mapping Project Segment to Component, since segments seem to align with parts of the application rather than timeline-based deliverables.

  • Feature → Epic

  • Stories, tasks, subtasks → Base-level work or smaller

❓ Questions for the community

  1. Is mapping “Project Segment” to Components a recommended approach?
    Or would we be better off creating a custom field for this type of categorization?

  2. Can Components or custom fields support useful reporting (e.g., progress % or roll-up reporting)?

  3. Do Components align well with iterative/incremental delivery, where a segment represents an area of the application rather than a time-bound Initiative or Epic?

  4. Is our overall mapping (Phase → Initiative, Segment → Component) aligned with Atlassian best practices?
    Or are we missing a better approach within the limitations of the standard hierarchy?

📌 Context

  • Epics feel too small for our “segment” concept.

  • Initiatives feel too large/cross-cutting.

  • We want to avoid misusing Epic/Initiative just to fit the hierarchy.

  • We cannot modify or extend the work item hierarchy.

Any advice, examples, or experience with similar setups would be greatly appreciated!

Thanks in advance!

1 answer

1 accepted

5 votes
Answer accepted
Walter Buggenhout
Community Champion
November 15, 2025

Hi @cvanduyn,

Jira has more to offer than the work type hierarchy to address challenges like these. I usually recommend using versions (releases) in Jira to model the phases of your projects, as they can be linked to any work type (regardless of hierarchy) and have start and end date attributes as well. That is pretty useful when you want to track progress of work inside those phases against target timelines.

With Jira projects being renamed to spaces now, you could very well call your projects, well - projects instead of initiatives.

From what you describe, components seem like a perfectly valid fit with your functional grouping of application parts. You should - however - not see them as part of the hierarchy, but really as metadata.

Since you mention being on a premium plan, you can leverage the Plans (advanced roadmaps) feature to look at a breakdown of your project work. The tool offers many ways to slice and dice your project (and even cross-project) data. One of those ways is grouping your plan / timeline views by component. That will indeed allow you to look into the progress and projected timelines grouped by component.

Hope this helps! 

cvanduyn November 15, 2025

Thanks Walter!

Grouping the Plan by components sounds like a splendid idea. I didn’t realize I could do that!

Best,
Cory

Like John Funk likes this

Suggest an answer

Log in or Sign up to answer