Atlassian Goals / Jira Native OKR Feature Gaps and Limitations

[Ariel Yadin _ Bazz OKR]

We've been rolling out OKRs across engineering and ops using Atlassian Goals, and we keep hitting the same structural wall.

The setup we're trying to model:

• Company-level Objective

- Company Key Result (e.g., 'Reduce p95 latency to <200ms')

- Team Objective that maps directly to that KR

- Team Key Results owned by individual squads

This is pretty standard cascade logic. A company's KR becomes the team's Objective. But in Atlassian Goals, the hierarchy doesn't seem to support this cleanly. You can nest goals, but the parent-child relationship treats everything as the same node type. There's no way to say 'this KR is also an Objective one level down' without duplicating the goal or losing the rollup integrity.

What we've tried so far:

• Creating the team objective as a child of the company KR works visually but breaks progress rollup logic
• Duplicating the KR as a standalone team objective and linking them manually creates drift, two sources of truth
• Flattening the whole thing to two levels loses the team ownership layer entirely

None of these feels right at scale. When you have 6+ teams, each with their own objectives rolling into 4-5 company KRs, the manual overhead compounds fast.

Curious whether others have found a workable pattern here:

• Are you modeling this differently in Atlassian Goals?
• Have you accepted the two-source-of-truth tradeoff and built a process around it?
• Or have you given up on native Goals for this use case and moved tracking elsewhere?

Would especially love to hear from folks running OKRs across more than 3 teams. What does your hierarchy actually look like in practice?

[Nick de Palézieux]

I have this issue as well. I would like to be able to have team objectives roll up to a company KR. But Atlassian Goals only allows team objectives to be children of company objectives. So the company KRs are siblings to the team objectives, which is not right.

I agree that this kind of cascading is standard in OKRs so I'm surprised that Atlassian chose to deviate from that.

I'm not even primarily looking for the status of the team objectives to roll up to the company KRs, I'd be happy just with the structure being reflected correctly so you can discover the right team objectives and assess coverate of the company KRs.

[Ariel Yadin _ Bazz OKR]

You’re describing exactly the friction we’re seeing.

Even if I ignore progress aggregation entirely, I still can’t model the logical relationship between a company KR and the team-level work that actually drives it.

What we’re aiming for is:

• Clear coverage: which teams are contributing to a specific company KR

• Clear ownership mapping: which team objective operationalizes that KR

• Minimal duplication / no drift

Right now, as you said, team objectives sit as siblings to company KRs under the same parent objective. Even without rollups, that’s a real limitation when you scale beyond a few teams.

Curious, have you found any workaround that preserves a single source of truth? 

[Ingo Wenke]

You wrote: "There's no way to say 'this KR is also an Objective one level down'".  

This is the main issue in how you are modeling OKRs. An KR should never be an Objective of a next layer in a cascade. It's intentionally agains what an objective should be. It's sounds like you would like to plan a classic WBS, not an OKR Cascade.

An objective ist sth like "find a new way to sail to India"

KR 1: get a crew

KR 2: get a ship

KR 3: sail west as long as possible

KR <> Objective. ever. 

If you want to model an OKR cascade like OKRs are intentionally made for, Atlassian Golas work pretty fine.

[Ariel Yadin _ Bazz OKR]

Hi @Ingo WenkeI get where you’re coming from, and I agree that in pure OKR theory, an Objective and a Key Result serve different purposes.

That said, in practice (especially in engineering orgs), the boundary often becomes operational rather than philosophical.

Using your example:

• “Get a ship” as a KR at the company level

• Becomes something like “Build and operationalize the ship” at the team level

At that point, the team needs:

• Its own objective (something actionable and owned)

• Its own KRs (delivery, quality, timelines, etc.)

So while it’s not a 1:1 semantic reuse, there is a very real parent-child dependency where:

• A company KR defines what success looks like

• A team objective defines how a specific group drives that success

The modeling challenge is expressing that linkage without duplicating intent or breaking alignment.

I don’t think this is a WBS vs OKR issue, it’s more about:

• Maintaining alignment across layers

• While allowing teams to operationalize outcomes independently

How you handle this in practice at scale:
When multiple teams contribute to a single company KR, how do you ensure: coverage (nothing falls through the cracks), clear ownership per team, and visibility back to that KR without introducing duplication somewhere in the system?

[Ingo Wenke]

Hi @Ariel Yadin _ Bazz OKR ,

the way we use it ist as following.

Our BHAG and 1HAG are both goals.

Each year is splitter into several month long OKR cycles.

Each OKR is defined as a goals with key results (formerly each KR was a project). Tracking progress at the base layer is "out-of-the-box" by goals. The progress of the 1HAG a the BHAG ist tracked with their own metrics - like we want it to track. Why? By only achieving each OKR does not mean to achieve the 1HAG. Fulfilling several 1HAGs does not mean to achieve our BHGA.

Formerly we tried to do a number crunching like, we met 80% OKR Results on lower level, so we reached x% at an higher level. But reality was different. So we separated each level from each other and that was the magic, because there is no "automatic progress" on higher levels when achieving an OKR on a lower level.

And in general we have either Jira Epics or full Jira Projects to manage each Key Results.

This might be the core difference of ours and yours approach. 

[RMohammed]

It is common, acceptable practice to cascade KRs by them becoming team-level Objectives: https://www.whatmatters.com/okrs-explained/top-down-okrs-cascading