Setting Up OKRs in Jira with Foundation Lenses

You can run OKRs inside Jira without buying a separate OKR tool. Model Objectives as a custom issue type, Key Results as Epics, and Initiatives as Stories or Tasks. Then use a Foundation Lens for the cross-project rollup and quarterly cadence. Here's the full setup, where it works, and where a dedicated OKR platform still wins.

What is the OKR model and how does it map to Jira?

OKRs (Objectives and Key Results) are a goal-setting framework popularized inside Intel in the 1970s by Andy Grove and spread across Silicon Valley by John Doerr's Measure What Matters. The structure is intentionally small: one Objective is a qualitative, inspirational statement of what you want to achieve this quarter. Three to five Key Results attached to that Objective are quantitative measures of whether you achieved it. Below the KRs sit the Initiatives — the actual projects and tasks your team will run to move those numbers.

In Jira, this tree maps cleanly to four levels. An Objective becomes a custom Jira issue type (Standard level, above Epic). A Key Result becomes an Epic. An Initiative becomes a Story, Task, or set of Stories linked to the KR Epic. Work-level tasks (sub-tasks or child stories) roll up into their parent Initiative. The whole chain is visible in one place when you build a Foundation Lens across the projects involved — which is the part native Jira has no good answer for.

OKR concept	Definition	Jira issue type	Rollup in Foundation Lens
Objective	Qualitative, inspirational goal for the quarter	Custom Objective issue type (above Epic)	Top-level parent; aggregates scores from child KRs
Key Result	Quantitative measure of Objective success (3 to 5 per Objective)	Epic (with custom Target / Current / Progress fields)	Second level; progress shown via Target and Current columns
Initiative	A project or body of work that moves a KR	Story or Task linked to the KR Epic	Third level; grouped under its parent KR
Task	Individual unit of execution	Sub-task or child Story	Fourth level; status rolls up via Foundation's tree

Why do most Jira OKR setups fail?

Three failure modes show up repeatedly when teams try to run OKRs in Jira without Foundation or a dedicated tool.

Too granular. Teams create 30 KRs per quarter because Jira makes it easy to make issues. The OKR discipline is three to five KRs per Objective, and no more than three Objectives per team per quarter. If your Jira OKR project has 200 open KR Epics, the framework has already collapsed into a glorified to-do list. The cure is editorial restraint, not tooling — but a Foundation Lens at least surfaces the bloat visibly so leadership can cut it.

No rollup. Native Jira shows you a single Objective with its child Epics inside one project. It does not roll up a cross-functional Objective where KRs live in engineering, KRs live in growth, and KRs live in customer success — three different Jira projects with different workflows. Without a cross-project view, each team tracks their own KRs in isolation and nobody can see the full Objective state until a manually maintained slide deck appears the night before the QBR.

Stale. The fatal pattern: OKRs are set in week one, typed into a wiki page, and never updated until week thirteen when someone asks why we missed them. Christina Wodtke's Radical Focus prescribes a weekly Monday commitment plus Friday confidence check — a rhythm that only works if updating a KR takes thirty seconds, not thirty minutes. A Foundation Lens with inline-editable Current Value columns makes the Friday update cheap enough that it actually happens.

How do you structure Objectives and Key Results in Jira issue types?

The recommended Jira structure has three pieces: a dedicated OKR project, a custom Objective issue type above Epic, and a set of custom fields on both Objective and KR Epics.

The OKR project is a standalone Jira project (company-managed is fine; team-managed also works) that contains only Objective and KR issues. Initiatives stay in their home projects — Engineering, Growth, Support — and get linked to their parent KR. This separation keeps the OKR project's issue count small and clean while the actual delivery work lives where it already lives.

The custom Objective issue type sits at Standard level (same tier as Epic). Atlassian documents the process at Add, edit, and delete an issue type. Give it a distinctive icon (many teams use a target or flag) so Objectives are visually distinct from delivery Epics in every view.

The custom fields are where the quantitative structure lives. At minimum: Target Value (number), Current Value (number), Progress Percent (number, 0-100), and Timeframe (short text, e.g. Q2-2026). Optionally add Confidence (1 to 10 number) for Wodtke's Friday check, and KR Type (single-select: Committed, Aspirational) to distinguish the stretch KRs from the must-hits.

How does Foundation Lens roll up quantitative KRs?

A Foundation Lens builds the Objective-KR-Initiative tree across every Jira project involved, using Sync Agents to pull the issues automatically. A JQL Insert agent with project = OKRS AND issuetype = Objective AND Timeframe = 'Q2-2026' brings in every Objective for the quarter. A Child Extend agent follows each Objective's issue links down to its KRs and then down to the Initiatives linked to those KRs — across project boundaries, which is the capability native Jira Plans does not reliably provide.

Once the tree is built, each column in the Lens displays the corresponding Jira field inline: Summary, Status, Target Value, Current Value, Progress Percent, Assignee, Timeframe. You edit the Current Value cell in place; Foundation writes the change back to Jira within seconds through the Forge inline-edit API.

Honest caveat. Foundation's MVP does not ship a formula engine. You cannot define a derived column that computes (Current / Target) * 100 as Progress Percent automatically — the formula engine is on the Q1 2027 roadmap. Today, you either update Progress Percent by hand when you update Current Value, or you set up a small Jira automation rule: when Current Value changes, set Progress Percent to (Current * 100 / Target), rounded. The automation lives in Jira, not in Foundation, and works fine.

Objective-level rollup (an Objective's score as the average of its child KR scores) also lacks a native Foundation formula. Three workarounds: maintain the Objective's Progress Percent manually at Friday check-in, use a Jira automation rule that averages the children when any child changes, or wait for the formula engine. Most teams pick the manual Friday check-in because the act of typing the number is the review conversation.

How do you handle the quarterly cadence (grading, reset)?

The OKR cadence has three recurring rituals (weekly commitment, weekly confidence check, quarterly grading) and one hard reset every three months.

Weekly commitment (Monday, 15 minutes). Open the Lens, review every KR, and each KR owner names the one to three moves they will make this week to push the Current Value. This is the operational conversation — where does attention go.

Weekly confidence check (Friday, 15 minutes). Each KR owner gives a 1-to-10 confidence score for hitting the quarter-end target, plus a one-sentence reason. The trend across Fridays is more predictive than any single snapshot. Atlassian's own OKR guide describes a similar Monday-Friday rhythm.

Quarterly grading (final week). Each KR gets a final score: final Current Value divided by Target, capped at 1.0. An Objective's score is the average of its KR scores. The canonical OKR range is 0.6 to 0.7 — consistently scoring 1.0 means the Objectives were sandbagged, scoring 0.3 means the quarter lost focus or the targets were fantasy.

Reset (quarter boundary). In Foundation, the clean pattern is: duplicate the current Lens, rename the copy to OKR-Q-prior, archive it as a historical record, then delete the Sync Agents in the original Lens and re-create them with the new quarter's Timeframe filter. You keep the column configuration and views; only the data scope rolls forward.

When should you use a dedicated OKR tool instead?

Jira plus Foundation covers the common case. There are real scenarios where a dedicated OKR platform — Gtmhub, Ally, WorkBoard, Quantive, Lattice — earns its separate subscription.

Heavy non-engineering KR load. If half your KRs are revenue targets, churn rates, NPS, hiring pipeline, or brand metrics that don't correspond to Jira issues at all, a dedicated OKR tool with native integrations to Salesforce, Zendesk, Workday, and Amplitude will save you the manual data entry. In Jira, those KRs still work but require somebody to type the current number into a field every week.

Executive alignment dashboards. Gtmhub and its peers ship weighted-alignment maps, heat-mapped scorecards, and cross-company roll-up dashboards designed for a CEO. Foundation gives you a grid with conditional formatting — honest but not polished for a board deck. If “make the OKR dashboard look good for the board” is on your quarterly agenda, a dedicated tool is usually worth it.

Weighted KRs and formula-heavy scoring. If your scoring rubric involves weighted averages, threshold bonuses, or non-linear grading curves, you will hit Foundation's lack of a formula engine quickly. A dedicated OKR tool bakes that math in; Jira plus Foundation gets you to linear percentage progress and no further until the Q1 2027 formula engine ships.

When Jira plus Foundation is enough. You're a mostly-engineering or mostly-product org. Your KRs are features shipped, latencies reduced, experiments run, bugs closed. Your team already lives in Jira. You want the OKR work to happen where the delivery work happens, not in a second tool nobody logs into. This is a large slice of Foundation's audience, and it's the case the rest of this guide is optimized for.

Step-by-step — building your first OKR Lens

The full setup takes about three days of elapsed time if you need admin approvals for the custom issue type, and maybe four hours of hands-on work. The six steps:

Create the Objective custom issue type. In Jira Cloud, go to Jira Settings, Issues, Issue types. Create a new Standard issue type called Objective with a distinctive icon. Associate it with the issue type scheme used by your OKR project. This gives you a top-level container above Epic that won't be confused with normal delivery work.
Create OKR-specific custom fields. Add three number custom fields to your Objective and Key Result issue types: Target Value, Current Value, and Progress Percent. Add a short text Timeframe field (e.g., Q2-2026). Scope the fields to the OKR project only so they don't pollute other project screens.
Set up the OKR project and issue hierarchy. Create a dedicated Jira project (company-managed or team-managed both work) called OKRs or Strategy. Create one Objective per company or team goal. Under each Objective, create three to five Key Results as Epics linked via Epic Link or a parent custom field. Under each KR, link the Initiatives and Stories that actually move that metric — these often live in other Jira projects.
Build the Foundation Lens with a Sync Agent. In Foundation, create a new Lens called Q-current OKRs. Add a JQL Insert Sync Agent with the query project = OKRS AND issuetype = Objective AND Timeframe = 'Q2-2026'. Then add a Child Extend Sync Agent that pulls each Objective's linked Key Results and their child Initiatives. The Lens now contains the full Objective to KR to Initiative tree, spanning every Jira project those Initiatives live in.
Configure the Lens view columns. Open the column picker and enable Summary, Status, Assignee, Target Value, Current Value, Progress Percent, and Timeframe. Save the configuration as a view called Weekly Check-in. Add a second view called Exec Summary with just Summary, Progress Percent, and a red-amber-green conditional format based on Progress Percent thresholds (below 40 red, 40 to 70 amber, above 70 green).
Run the weekly review ritual. Every Friday, open the Lens, click inline on each KR's Current Value cell and update the number, then update Progress Percent manually (or let a Jira automation rule compute it). In the Monday meeting, sort by Progress Percent ascending to surface the KRs most at risk. At quarter end, duplicate the Lens, rename it Q-prior, archive it, and delete the current-quarter Sync Agents to start fresh for Q-plus-one.

When the Lens is live and the team has run one full weekly cycle, two things change. First, Friday updates take minutes instead of hours because the data lives where the work lives. Second, the Monday commitment meeting has actual information in it — you can see which KRs have drifted red since last Friday, and the conversation starts there.

Frequently asked questions

Do I need a dedicated OKR tool if I use Jira?

Not necessarily. If your Objectives and Key Results are tracked against work that already lives in Jira — features shipped, bugs closed, experiments run — you can model the whole system inside Jira with a custom Objective issue type at the top, Epics as Key Results, and a Foundation Lens for the cross-project rollup. You need a dedicated OKR tool (Gtmhub, Ally, WorkBoard, Quantive) when you have many non-engineering KRs — sales targets, NPS, HR metrics — that don't map to Jira issues, or when leadership wants an executive scoring dashboard with weighted alignment maps. For a mostly-engineering org, Jira plus Foundation covers the 80% case without a second subscription.

How do I score quantitative KRs in Jira without a formula engine?

Use Jira custom number fields and read them with the Foundation Lens. Add two custom number fields to your Key Result issue type: Target Value and Current Value. A Lens column can display both plus a manual percentage you enter in a third Progress field. Foundation's MVP does not ship a formula engine — calculating (Current / Target) * 100 as a derived column is on the Q1 2027 roadmap. Until then, teams either update the Progress field weekly by hand or wire a small Jira automation rule that sets Progress when Current changes. For KRs without Jira-native numbers (revenue, NPS) you'll maintain the values manually either way.

How often should we update OKR progress?

Weekly is the standard per Christina Wodtke's Radical Focus and Doerr's Measure What Matters. The cadence that works for most teams: a 15-minute Monday commitment meeting (what will we do this week to move the KRs) and a Friday confidence check (on a 1-to-10 scale, how likely are we to hit each KR by quarter end). Updating daily is noise; updating monthly lets drift hide. A Foundation Lens makes the weekly update cheap because the KR numbers live on Jira issues — you edit the Current Value cell inline and the whole rollup refreshes.

Should Objectives be top-down or bottom-up?

Both, mixed. The classic Google model is roughly 60 percent top-down (set by leadership to enforce strategic focus) and 40 percent bottom-up (set by teams to capture local knowledge). Pure top-down OKRs tend to feel like assignments and get gamed. Pure bottom-up OKRs drift from strategy and produce a pile of unrelated goals. In Jira, you model this by linking child Objectives to a parent Objective with an Epic-Link-style field or a Jira issue link, so the alignment is explicit and visible in the Foundation Lens tree.

What happens to OKRs that don't get hit at quarter end?

Grade them, learn from them, don't punish them. The OKR model explicitly expects a 0.6-to-0.7 average score on a 0-to-1 scale — hitting 1.0 every quarter means the Objectives were too easy. At quarter end, each KR gets a final score based on final Current Value divided by Target, an overall Objective score is the average of its KRs, and the team writes a short retrospective (what moved the metric, what didn't, what to carry forward). In Foundation, you snapshot the Lens as of the quarter-end date and archive it; the next quarter starts with a new Lens for Q-plus-one.

Can a Key Result belong to multiple Objectives?

Technically yes in Jira (issue links are many-to-many), but in practice it creates accountability confusion and double-counted progress. The OKR canon treats each KR as having exactly one parent Objective. If two Objectives genuinely share a metric, either merge them into one Objective or split the metric into two KRs with different targets — for example, a shared 'reduce support ticket volume' metric becomes 'reduce P1 tickets to X' under the Reliability Objective and 'reduce billing tickets to Y' under the Finance Objective. Single-parent discipline keeps the rollup math and the accountability both honest.