OKRs in a Task Tracker: Linking Company Goals to Team Work

Here’s how OKRs map onto a task tracker: the quarterly objective becomes the top level (an Initiative in Plane or a level above the epic in Jira), each key result becomes a module or epic with its metric in the description, and the work that moves the metric becomes work items in sprints. Once a week, the team updates the current value and its confidence in hitting the target. That way, goals stop living in a slide deck and become visible where the team works every day.

This article is for founders, engineering leads and product managers who are introducing OKRs or trying to revive them after a failed first quarter. Below: how OKR levels map onto Plane and Jira, why a key result is not a task, step-by-step setup, a quarterly calendar, a check-in format and the mistakes that make teams abandon OKRs.

Why OKRs die in slide decks

A typical first quarter with OKRs goes like this. At the start of the quarter, leadership writes the objectives in slides or a spreadsheet. Teams draft key results and everyone agrees. Then regular work begins in the tracker, where the goals are never mentioned. At the end of the quarter, someone opens the spreadsheet and discovers that half the key results didn’t move, even though the team was busy the whole time.

The problem isn’t the methodology but the gap between goals and tasks. If a sprint has no tasks linked to a key result, that result won’t move. If the link exists but nobody sees it, priorities are still set by whoever asks loudest.

A task tracker closes that gap: objectives, key results and tasks live in one system and are linked to each other. During sprint planning, you can see which tasks serve the goals and which don’t.

How OKR levels map onto a tracker

OKR level	Example	Plane	Jira
Objective	“Make onboarding for new customers self-serve”	Initiative at the workspace level	A level above the epic in Advanced Roadmaps or an issue in a separate goals project
Key result	“Share of customers who complete onboarding without calling a manager, from baseline to target”	Module or epic in the team’s project, linked to the initiative	Epic linked to the objective
Team initiative	“Step-by-step setup wizard”	Work items within the module, a sub-module if needed	Stories and tasks within the epic
Two-week work	“Plan selection screen in the wizard”	Work items in a cycle	Issues in a sprint
Weekly check-in	Metric value, confidence, blockers	Comment on the initiative or a page in Pages	Comment on the epic or a Confluence page
Progress overview	All company objectives on one screen	Dashboards and workspace-level views	Jira dashboards and Advanced Roadmaps

In Plane, initiatives bring together work from several projects, so an objective that engineering, design and support all work toward is visible as a whole. In Jira, Advanced Roadmaps gives a similar picture; check whether it’s available on your plan.

A key result is a metric, not a task

The most common mistake is phrasing key results as a list of work. “Launch the setup wizard,” “Rewrite onboarding,” “Run five interviews.” These are initiatives, not results. You can complete them 100% and move nothing.

A key result answers the question “how will we know the objective has been achieved?” It has a metric, a baseline at the start of the quarter and a target at the end. Tasks are hypotheses about how to move the metric.

This has an important implication for the tracker. A module’s progress as a percentage of closed tasks is not the same as the key result’s progress. A module can be fully closed while the metric stays flat. So keep a separate block in the module or epic description:

• the metric and where its value comes from;
• the baseline at the start of the quarter;
• the target value;
• the current value and the date it was updated;
• the team’s confidence in achieving it.

The key result owner updates the current value at the weekly check-in. The percentage of closed tasks shows whether the team is working. The metric shows whether what the team is doing works.

How to write an objective and key results

A good objective briefly describes the desired state and is clear to everyone on the team without explanation. It contains no numbers: numbers live in the key results. A bad objective sounds like “improve the product” or “increase efficiency,” and afterward no one knows what to do on Monday.

A good key result passes four tests:

1. Measurable. There is a metric and it’s clear where its value comes from.
2. Has a starting point. The baseline is known at the start of the quarter.
3. Within the team’s control. The team can influence the metric through its own work rather than waiting on decisions from other departments.
4. Doesn’t describe the work. The wording doesn’t imply a single way to achieve the result.

An example for a SaaS product team. Objective: “New customers start using the product without help from a manager.” Key results: the share of customers who complete setup in their first week grows from baseline to target; the number of support requests about setup goes down; time from sign-up to first meaningful action gets shorter. Initiatives, such as a setup wizard, in-app tips and onboarding emails, then appear as modules and work items in the tracker.

An example for an IT department. Objective: “Employees get a working setup without waiting.” Key results: time to grant access to a new employee drops to the target value; the share of requests closed within the SLA grows. Tasks such as automating access provisioning, request templates and a policy go into the IT department’s cycles.

Set target values yourself, based on your own baseline data. Other people’s benchmarks from slide decks are nearly useless here: every team has its own starting point.

Setting up OKRs in Plane, step by step

1. Quarterly objectives. Create initiatives at the workspace level. Put the quarter in the name, and in the description explain why the objective matters and who owns it.
2. Key results. In the project of each team working toward the objective, create a module or epic for each key result and link it to the initiative.
3. Metrics. In the module description, fill in the block with the metric and its baseline, target and current values.
4. Work items. Create the work that moves the key result inside the module. During cycle planning, work items from OKR modules get priority.
5. An “outside OKRs” label. Operational work and support also go into cycles, but with a label. That way, the retro shows what share of time went to the goals.
6. A leadership view. At the workspace level, build a view and a dashboard with all of the quarter’s initiatives and their modules.
7. A quarter page. In the Wiki, create a page with the quarter’s objectives, check-in rules and the results of the previous quarter.

If the team doesn’t work in cycles yet, set up sprints first: without regular planning, OKRs have nothing to attach to. We described how to do that in our article on sprints and cycles in Plane.

OKRs in Jira: what to use

There’s no single right way to run OKRs in Jira, but a working setup looks like this. A key result is set up as an epic in the team’s project. The objective becomes a hierarchy level above the epic, configured in Advanced Roadmaps, or an issue in a separate goals project that the epics link to. The key result’s metric is kept in the epic description or in a separate field.

For reporting, you build a JQL filter for the quarter’s epics and put it on a dashboard. Weekly check-ins are convenient to run on a Confluence page if the company already uses it. For full OKR reporting with cascading and scoring, there are Atlassian Marketplace apps; their cost is separate from Jira licenses.

If you’re still choosing between Plane and Jira, keep in mind that initiatives are built into Plane and don’t require configuring a hierarchy, while Jira is more flexible but needs more administration.

Quarterly calendar and weekly check-in

Week	Event	What we do in the tracker
2 weeks before the quarter	Leadership drafts objectives and discusses them with teams	Draft page in the Wiki, team comments
1 week before	Teams draft key results and initiatives	Draft modules or epics, metric baselines
1	Approval and quarter kickoff	Initiatives and modules created and linked, first cycle planned
Every week	Check-in, 15–30 minutes per team	Current value and confidence updated for each key result
6–7	Mid-quarter review	Key results that no longer make sense are revised; decisions recorded on the quarter page
12	Preliminary scoring	Owners record the expected final value
13	Final scoring and retro	Each key result scored, retro page, unfinished work moved into the next quarter’s draft

Check-in template for each key result:

• the metric’s current value and the change over the week;
• confidence in achieving it: high, medium or low;
• what’s getting in the way;
• what the team is doing this week, with links to cycle work items.

It’s convenient to score the final result on a scale from 0 to 1. For ambitious objectives, a score around 0.7 is considered normal. If a team hits 1.0 on everything every quarter, its goals are too cautious.

Kazakhstan context. Many IT teams are distributed between Almaty, Astana and remote work, with some employees working from other cities. In such a team, the weekly check-in works better written and asynchronous: the key result owner updates the value and writes a comment in the tracker by a set time, and a call is only held for objectives with low confidence. That way, status doesn’t get lost in WhatsApp voice messages. Write objectives in a language everyone involved understands: bilingual teams sometimes need a Kazakh version. If key result metrics contain customer data and it matters to the company to keep it in Kazakhstan, choose a self-hosted installation of the tracker.

Mistakes that make teams abandon OKRs

• Too many objectives. Eight objectives per team means there’s no focus.
• Key results as a task list. Everything is done, the metric didn’t move, and nobody noticed.
• No baseline. Without a starting point, you can’t tell whether there was progress.
• Monthly check-ins. By mid-quarter, it’s too late to change the approach.
• Linking to bonuses. Teams set safe goals, and OKRs stop being a tool for ambition.
• Cascading by decree. Objectives are pushed down from the top to every employee, teams don’t take part in writing them and don’t feel ownership.
• All work forced into OKRs. Support and operational tasks are formally tied to objectives, which distorts the progress picture.
• Goals outside the tracker. The OKR spreadsheet is in one place, the tasks in another, and the link depends on the manager’s memory.

In our experience, the first quarter with OKRs is almost always a learning quarter. That’s fine as long as the team changes the format afterward instead of giving up on goals. We described the overall process of rolling out a tracker, on which OKRs then build, in our article on implementing a task tracker in a company.

How we do it

We start with a diagnostic: how objectives are currently written, where tasks are tracked, whether teams have regular planning and where the metrics come from. Then we run a one-quarter pilot with one or two teams: we set up initiatives, modules and views in Plane or the hierarchy in Jira, and run the first check-ins together with the key result owners. After the quarter, we adjust the format and roll it out to the other teams.

Learn more about our approach on the Jira and Plane task tracker implementation service page.

---

Sources. Plane pricing and features: plane.so/pricing. New Plane features: Plane blog. Jira pricing: Atlassian price list.

Terms in plain words

OKR (Objectives and Key Results)

A goal-setting system: a qualitative objective for the quarter and two to four measurable key results for it. It helps the team understand which work really matters.

Key result

A metric with a baseline and a target value that shows whether the objective has been achieved. It is not a task: you can complete every task and the metric won’t move.

Check-in

A short weekly OKR review: the metric’s current value, confidence in achieving it and what’s getting in the way. In a distributed team, it’s convenient to do it in writing in the tracker.

Initiative (in Plane)

The top level in Plane that brings together work from several projects. You create an initiative for a quarterly objective and see how engineering, design and support are working toward it.

Epic

A large chunk of work made up of many issues. In Jira, a key result is usually set up as an epic, with its metric kept in the description.

Advanced Roadmaps

A Jira feature for planning above the epic level. It is used to set up the objectives level; availability depends on your plan.

JQL

Jira’s query language for filtering issues by conditions. It is used to build a report on the quarter’s epics and display it on a management dashboard.

SLA

An agreed time to handle a request, such as granting access to a new employee. The share of requests closed on time can be a key result for an IT department.