From SHV to Hiera: Bringing Above-Epic Hierarchy and Capacity Planning to Jira Standard

[#1]

Hey everyone!

A few months ago, I posted here looking for feedback on a Forge app I was building to solve a specific pain point: visualizing work above Epics without having to upgrade to Jira Premium. The feedback was incredibly helpful (thanks to everyone who reached out!).

Back then, it was called Strategic Hierarchy View (SHV). Quite a mouthful. Since then, the app has grown from a simple hierarchy viewer into a full planning workspace. So, to keep things simple, SHV is now officially Hiera.

Along with the new name, I’ve just shipped an update that addresses the two biggest headaches I hear from Jira Standard teams: Strategic Parents and Capacity Planning. Here is how they work and why I built them.

---

The "Jira Premium Gate" is Real

We’ve all seen this story play out: A team grows, and suddenly you need a layer above Epics (like Initiatives or Themes) to track company goals.

In native Jira Cloud, the official answer is: "Upgrade to Premium to get Advanced Roadmaps." But if all you need is a 3-level hierarchy and a simple timeline, upgrading a 50-user team just for that is a budget-killer. So what do teams do instead? They build a massive Excel sheet that gets out of sync in five minutes.

Hiera is my attempt to build a lightweight, native alternative that lives entirely inside Jira Standard.

---

1. Hierarchies Above Epic (Without Native Link Mess)

You can now map levels like Theme ➔ Initiative ➔ Epic ➔ Story directly in Jira Standard.

• Keep your native links clean: Hiera stores these strategic relationships in Forge’s Key-Value Storage, so you don't have to mess up your native issue linking structure.
• Native JQL Search: I mirrored these custom parents to a Jira issue property (hieraParent). This means you can still run JQL queries like hieraParent = "PROJ-123" to find all stories under a specific initiative.

---

2. The "Excel Killer": Cross-Project Capacity

Another major reason teams go back to spreadsheets is tracking who is doing what across multiple projects. I added three new tabs directly to the global view to solve this:

• Capacity Heatmap (Auto): A zero-setup grid that scans your projects and highlights who is overloaded each week. Click any cell to see the exact issues causing the bottleneck.
• Workload Matrix (Manual): A simple spreadsheet-like grid where developers can declare the hours they expect to spend on each project. It auto-saves as they type.
• Team Aggregate: A single table for admins to spot overallocated team members and adjust their weekly hours in one click.

---

Built Solo on Forge

Since the app is built on Atlassian Forge, all data stays securely within Confluence and Jira. As a solo dev, I don't have a sales team or prioritization meetings—if you tell me a feature is missing or a bug is blocking you, I usually have the fix live in production in less than 24 hours.

I’d love to get your honest thoughts:

• If you're on Jira Standard, how are you currently tracking work above Epics? Are you still stuck in Excel?
• What’s the one feature you wish Jira Standard had out of the box for team capacity?

Let's chat in the comments! If you want to check it out, Hiera is available on the Atlassian Marketplace.

[Martin Runge]

Hi @Germán Morales _ Hiera

Looks interesting. I'll especially check out the Capacity Heatmap feature.

Cheers, Martin

[Germán Morales _ Hiera]

Hi @Martin Runge

Thanks for stopping by and checking it out!

I’d love to hear your thoughts on the Capacity Heatmap once you've had a chance to test it. It was actually one of the most requested features from teams who were tired of maintaining separate Excel sheets just to spot bottlenecks.

Also, just as a heads-up: I'm releasing a new version in a few days that introduces planned cost tracking and several usability improvements, so stay tuned!

If you have any feedback or if there's a specific use case you'd like to see covered, please let me know.

Cheers,
Germán