---
title: "How to Grade OKRs and Run Check-ins"
description: "How to grade OKRs on a 0.0 to 1.0 scale, record dependencies, run a weekly check-in and monthly review that decide things, and turn a 0.4 into a better quarter."
canonical_url: "https://builderscamp.com/guides/other/how-to-grade-okrs"
date_published: "2026-10-05"
date_modified: "2026-10-05"
author: "Paulo Tavares"
publisher: "Builders Camp"
guide_class: "other"
---

# How to grade OKRs: check-ins, scoring and retros without status theatre

**TL;DR:** Grade OKRs once, at the end of the quarter: score each key result from 0.0 to 1.0 by how far it moved from baseline toward target, average them into the objective's grade, and read aspirational OKRs against a 0.6 to 0.7 sweet spot and committed OKRs as pass or fail at 1.0. During the quarter, a weekly written check-in reports numbers, forecasts and blockers, and a monthly review is the only meeting allowed to re-staff, re-scope or drop an OKR.

A grade is only useful if the number it summarises was written down before the quarter began and checked often enough that the grade surprises nobody. Google's [re:Work guide to OKRs](https://rework.withgoogle.com/intl/en/guides/set-goals-with-okrs) grades key results on a 0.0 to 1.0 scale and says "the expectation is to get an average of 0.6 to 0.7 across all OKRs." It is just as clear about the limits of the exercise: "This isn't a science but it's important to be honest and, more than anything, consistent with the grading process."

Consistency is the part most teams skip. One team grades from zero, another from last quarter's value, a third rounds up because the work was hard. This guide gives one grading procedure, two rituals that feed it, and a filled quarter of scores from a fictional company, so you can copy the whole loop rather than just the scale.

## How do you grade an OKR at the end of the quarter?

Grade each key result on its own, then roll the grades up. Four steps, in this order:

1. **Score the distance covered, not the end value.** Grade = (final value minus baseline) divided by (target minus baseline), rounded to one decimal and capped at 1.0. A key result that set out to move online bookings from 34 to 50 percent and landed at 43 percent covered 9 of 16 points, so it scores 0.6. Scoring 43 against 50 as 0.86 rewards the team for the 34 points it started with.
2. **Average the key results into the objective.** What Matters' [scoring guide](https://www.whatmatters.com/faqs/how-to-grade-okrs) says "take the average score of its Key Results. Each KR counts equally toward the total OKR score." re:Work allows some weighting; if you weight, agree the weights in week 1, never at grading time.
3. **Read the grade against the OKR's type.** Google's [OKR playbook](https://www.whatmatters.com/resources/google-okr-playbook) splits OKRs into two kinds: "The expected score for a committed OKR is 1.0," while "Aspirational OKRs have an expected average score of 0.7, with high variance." A committed OKR is pass or fail. An aspirational one is read on a band.
4. **Colour the aspirational grades with a fixed band.** For aspirational OKRs, What Matters reports that Google treats 0.7 to 1.0 as green, 0.4 to 0.6 as yellow and 0.0 to 0.3 as red. Pick your bands once, publish them, and keep them for at least a year so scores are comparable across quarters.

Binary key results (a migration finished or it did not) score 0.0 or 1.0. re:Work's own example of a granular one is a key result to launch six features where three shipped, graded 0.5. Treat that example as a warning more than a model: if your key result counts launches, the grade measures output, and the [guide to writing good OKRs](https://builderscamp.com/guides/other/how-to-write-good-okrs) explains how to rewrite it around the change the launches were meant to cause.

## Should you grade mid-cycle, or only at the end?

Grade once, at the end. During the quarter, forecast. The difference matters because a grade is a judgement about a finished quarter, while a forecast is a claim about where the number will land if the current plan holds, and it is supposed to move.

What Matters makes the same split in [why it does not grade OKRs weekly](https://www.whatmatters.com/faqs/weekly-okr-grading-check-in): reviewing is about the "action to get it back on track," while grading is a judgement on whether the goal was met. re:Work suggests a mid-quarter check-in before the final grade, and "an end of quarter check-in can be used to prepare ahead of the final grading."

In practice, each key result owner reports two numbers every week: the current value and a forecast end grade on the same 0.0 to 1.0 scale. The forecast is what the monthly review reads. If the forecast has fallen two months in a row and nobody has made a decision about it, the ritual is failing, whatever the grade turns out to be.

## What does a weekly OKR check-in look like?

A weekly check-in exists to find blockers early, and it is written first and spoken second. The template below is the whole ritual.

| Field | Weekly check-in |
|---|---|
| Who attends | Key result owners and the product trio (PM, tech lead, designer). Managers read the doc; they do not attend. |
| Format | Async doc updated by Monday 12:00, then a 15-minute live slot on Tuesday that only covers rows marked red or changed. If no row is red, cancel the slot. |
| What gets reported | Per key result: current value, change since last week, forecast end grade (0.0 to 1.0), one blocker or "none", and the owner's initials. No activity lists. |
| What gets decided | Who removes each blocker and by when. Whether any key result goes on the monthly review agenda. Nothing about targets: the weekly slot cannot change a key result. |

What Matters' list of weekly check-in questions is a good test of whether yours is working, including "Are there any blockers that could stop you from achieving your objectives?" If the honest answer for every row is "none" week after week while the forecasts slide, people are reporting activity instead of numbers.

Three rules keep the check-in from becoming status theatre. A row with no change and no blocker is one line long. Anyone who reads the doc and has nothing to unblock skips the live slot. And the doc shows the number, not a description of the work: "Online bookings 41 percent, up 1 point, forecast 0.6" says more than a paragraph about the new booking widget.

## What does a monthly OKR review decide?

The monthly review is the only meeting allowed to change the plan. That rule is what stops the weekly check-in from re-litigating targets, and it gives at-risk OKRs a date by which someone must decide.

| Field | Monthly review |
|---|---|
| Who attends | Head of product, engineering lead, the owners of any objective forecast yellow or red, and one person from each team named as a dependency. |
| Format | 45 minutes live, with a one-page pre-read sent 24 hours before. The pre-read lists every objective with its forecast grade and colour, and every committed OKR with "on track" or "at risk". |
| What gets reported | Forecast grade per objective, the forecast trend over the last four check-ins, dependency status, and any resource request. |
| What gets decided | For each at-risk OKR, one of four outcomes, written into the OKR doc: continue as is, re-staff, re-scope with a dated note, or drop and carry forward to next quarter. Committed OKRs at risk get an escalation owner the same day. |

re:Work frames this monthly use of OKRs as calibration: a chance to "abandon objectives that are clearly not going to happen, and increasing attention on borderline objectives that will benefit from additional resources." Google's playbook goes further for committed OKRs: a team that cannot credibly promise a 1.0 "must escalate promptly," and "Escalating in this (common) situation is not only okay, it is required."

When two teams need the same people to rescue their OKRs, the monthly review becomes a resourcing decision; [how to prioritize between two teams competing for the same engineers](https://builderscamp.com/guides/other/how-to-prioritize-between-two-teams) works through that call step by step.

## How should you record a key result that depended on another team?

Keep two grades and one log. The grade of record is the raw number, calculated exactly as above, and it is the only one that gets averaged and published. The self-assessed grade sits next to it and carries the team's judgement. What Matters' [end-of-cycle guide](https://www.whatmatters.com/okrs-explained/grading-okrs) shows why the second column exists: a PR team that landed two of three national news placements scored 0.67, but one placement led directly to two clients, so a self-assessed 0.9 was fair; a team that landed two small placements because it was late with releases might self-assess 0.3.

John Doerr's line, quoted in What Matters' piece on [grading versus reflecting](https://www.whatmatters.com/faqs/grading-and-reflecting-on-okrs-whats-the-difference), is the principle: "In evaluating OKR performance, Objective data is enhanced by the goal setter's thoughtful, subjective judgement." The danger is that the subjective column quietly replaces the objective one. Keeping both stops that.

The dependency log has six columns: key result, what it depended on, the week the dependency was declared, the date promised, the date delivered, and the owner's estimate of what the gap cost the grade. One rule makes it useful. A dependency nobody could have foreseen can justify a higher self-assessed grade. A dependency declared in week 1 that then slipped is a planning input, not an excuse: the owner knew the risk and should have built a fallback or raised it at the monthly review.

## What does a filled quarter of OKR scores look like?

Physiolane is a fictional booking app for physiotherapy clinics. All numbers below are illustrative. Its product team ran three objectives from July to September.

| Key result | Type | Baseline to target | End of July forecast | End of August forecast | Final value | Grade of record | Self-assessed |
|---|---|---|---|---|---|---|---|
| O1: Patients book and keep appointments without calling the clinic | Aspirational | | | | | **0.6** (yellow) | |
| KR1.1 Appointments booked online | Aspirational | 34 to 50 percent | 0.7 | 0.6 | 43 percent | 0.6 | 0.6 |
| KR1.2 No-show rate | Aspirational | 11 to 7 percent | 0.6 | 0.3 | 9.4 percent | 0.4 | 0.5 |
| KR1.3 Median days to rebook after a cancellation | Aspirational | 4 to 2 days | 0.5 | 0.7 | 2.5 days | 0.8 | 0.8 |
| O2: Clinics on the new billing plan are invoiced correctly from day one | Committed | | | | | **Missed** (red) | |
| KR2.1 Clinics migrated to new billing by 31 August | Committed | 0 to 412 | On track | On track | 412 by 29 August | 1.0 | 1.0 |
| KR2.2 Billing tickets per 100 clinics, every month | Committed | 3 or fewer | On track (2.1) | At risk (4.6) | 2.1, 4.6, 2.4 | Missed | Missed |
| O3: Clinic owners run their week from the Physiolane dashboard | Aspirational | | | | | **0.2** (red) | |
| KR3.1 Weekly active clinic owners | Aspirational | 38 to 60 percent | 0.5 | 0.2 | 41 percent | 0.1 | 0.1 |
| KR3.2 Owners exporting a weekly report | Aspirational | 120 to 300 | 0.4 | 0.3 | 168 | 0.3 | 0.3 |

The dependency log for the quarter had two rows. KR1.2 depended on SMS reminders; the SMS provider changed its sender rules in August and reminders stopped for two weeks. Nobody had declared that risk, because nobody had seen it coming. KR3.1 depended on the data team's new reporting pipeline, declared in week 1, promised for week 4 and delivered in week 11.

Three readings come out of the table. The aspirational average is 0.4 (O1 at 0.6, O3 at 0.2), below the 0.6 to 0.7 band, and almost all of the shortfall sits in O3. O2 is a committed miss, so it gets a postmortem, which Google's playbook says "is not intended to punish teams" but "to understand what occurred in the planning and/or execution." And the August forecasts already showed every bad result: KR1.2 at 0.3, KR2.2 at risk, KR3.1 at 0.2. The quarter was not lost at grading time. It was lost at the August review, which recorded those forecasts and decided nothing.

## Which retro questions turn a 0.4 into next quarter's learning?

Take KR1.2, the no-show rate at 0.4. A retro that stops at "the SMS provider broke reminders" learns nothing. Work through these questions in order, with the numbers on screen:

1. **How much of the gap did the dependency cost?** Weeks with reminders averaged 8.8 percent no-shows; the two weeks without averaged 13.0. With reminders all quarter, the rate would have been about 8.8 percent, a grade of roughly 0.55. The dependency cost about 0.15 of grade. The other 0.45 belongs to the plan.
2. **Was the target set against the do-nothing trend?** Reminders alone moved the rate from 11 to about 8.8 percent. Nothing else in the plan targeted no-shows, so 7 percent needed a second mechanism the team never named.
3. **When did we know, and what did we decide?** The August check-in forecast 0.3. The monthly review noted it and chose "continue as is" by default, without anyone saying so.
4. **If we had scored 1.0 on every key result, would the objective be true?** This is the playbook's litmus test, "Is it reasonably possible to score 1.0 on all the Key Results, but still not achieve the intent of the Objective?" Here, no: patients still call clinics to reschedule, and no key result measured that.
5. **What would we write differently?** What Matters' end-of-cycle questions belong here: "If we could rewrite a goal that we achieved in full, what would we change?" and "What have we learned that might change our approach in the next OKR cycle?"
6. **Carry forward, rewrite or drop?** The playbook says aspirational OKRs "should remain on a team's OKR list until they are completed," because dropping them "disguises persistent problems of prioritization, resource availability, or a lack of understanding of the problem/solution."

Physiolane's Q4 set changed in three ways as a result. KR1.2 carried forward with a second mechanism (a one-tap reschedule link in the reminder) and a new committed key result for the reminder itself: reminders delivered for at least 98 percent of booked appointments every week, with a backup SMS route. KR3.1 was rewritten around a leading measure the team could move without the pipeline. And the O2 postmortem found that the August ticket spike came from the last migration batch, which skipped the invoice preview step, so Q4's committed billing key result names the preview step explicitly. A 0.4 became three specific changes, which is the only reason to grade at all.

## Should you grade team OKRs or individual OKRs?

Grade team OKRs. Individual OKRs on a product team push the PM, the designer and the engineer toward separate scores for shared work, and the [cascading vs aligning OKRs guide](https://builderscamp.com/guides/other/cascading-vs-aligning-okrs) covers why most product organisations stop at company and team. Individual contributions still matter; they belong in the performance conversation, where they can be judged with context.

re:Work is direct about the boundary: "OKRs are not synonymous with performance evaluation." They can summarise what someone worked on and the impact it had, but they are not a complete way to evaluate a person or an organisation.

## Why should OKR grades stay out of compensation?

Because the fastest way to raise grades is to lower targets. Laszlo Bock, Senior Vice President of People Operations at Google from 2006 to 2016, says in What Matters' [piece on compensation](https://www.whatmatters.com/articles/laszlo-bock-divorce-compensation-from-okrs): "Objectives and Key Results should be totally divorced from compensation." Ryan Panchadsaram, What Matters co-founder, gives the mechanism in [a separate interview](https://www.whatmatters.com/articles/should-you-connect-okrs-and-compensation-spoiler-alert-no): when pay rides on goals, people deliberately aim low, and "You don't want to penalize people for aiming high."

The honest counterargument is sales. Bock himself says a sales organisation can be paid on quotas, while warning that any sales incentive plan creates perverse incentives. The Physiolane table shows the cost elsewhere: if KR3.1's 0.1 had cut the dashboard team's bonus, next quarter's target would have been 45 percent, not 60, and the grade would have looked better while the product got no closer to the objective. If your company must connect the two, use OKRs as one input to a performance conversation about scope, skill and impact, and keep the scores out of any formula. For the review itself, the [performance review template for product managers](https://builderscamp.com/guides/templates/product-manager-performance-review-template) rates a PM against a named competency model with evidence, rather than against a goal score.

## Is the grading overhead worth it for a small team?

For a team of five with two objectives, the whole grading pass takes under an hour, and most of the value comes from two habits: scoring from baseline rather than from zero, and reading the August forecasts as decisions waiting to be made. Skip the colour bands and the self-assessed column if they feel heavy. Keep the forecast column; it is what makes the end-of-quarter grade unsurprising.

The real risk is a different kind of theatre: a precise-looking grade on a key result that was never measurable. If a key result has no query that produces its number today, no grading procedure can fix it, and the stress test in [AI for OKRs](https://builderscamp.com/guides/tools/ai-for-okrs) is the quicker place to catch that before the quarter starts. For the starting structure of an objective with three key results, see the [OKR template](https://builderscamp.com/guides/templates/okr-template).

## Where can you practise running an OKR cadence?

[How to Design OKRs](https://builderscamp.com/bootcamps/how-to-design-okrs) is a one-week Builders Camp bootcamp with 6 microlessons, part of the Product Leadership Track. Its published topics include cadence, scoring and learning (running check-ins, scoring results and turning outcomes into next-cycle learning), alongside objective crafting, alignment across teams and common failure modes. Its practical challenge ends by asking you to design a weekly check-in and a monthly review that create accountability without busywork, which is the template above put under pressure.

Builders Camp runs live and self-paced bootcamps in product management and AI product building. See the How to Design OKRs bootcamp for dates and the full syllabus.

## Frequently asked questions

### How do you calculate an OKR score?

Grade each key result from 0.0 to 1.0 as the share of the distance from baseline to target that you covered, so a metric that moved from 34 to 43 percent against a target of 50 scores 0.6. The objective's grade is the average of its key results, unless you agreed weights at the start of the quarter.

### What is a good OKR score?

For aspirational OKRs, Google's re:Work guide puts the sweet spot at 0.6 to 0.7 averaged across all OKRs. A committed OKR is different: the expected score is 1.0, and anything less needs an explanation.

### How often should you grade OKRs?

Grade once, at the end of the cycle. During the quarter, report the current value and a forecast of the end grade every week, and review the forecasts monthly. Weekly grading turns check-ins into a scoreboard argument instead of a conversation about blockers.

### Should OKR scores affect bonuses or performance reviews?

Not directly. Laszlo Bock, who ran People Operations at Google from 2006 to 2016, says OKRs should be totally divorced from compensation, because tying pay to scores teaches people to set targets they know they will hit. OKRs can be one input to a performance conversation about scope and impact, never the formula.

### How do you score an OKR that depended on another team?

Grade the number as it landed, then record the dependency separately: who you depended on, when you declared it, the date promised and the date delivered, and your estimate of what it cost the grade. Adjust the grade only in the self-assessment column, and only for dependencies nobody could have planned around.

### Should you change a key result mid-quarter if it becomes impossible?

Raise it at the monthly review rather than editing it quietly. The review can re-staff it, re-scope it with a written note, or drop it. Google's OKR playbook warns that dropping an aspirational OKR for lack of progress disguises the problem, so a dropped one should be carried to the next cycle's list.

### Who should attend a weekly OKR check-in?

The people who own a key result and can unblock it: on a product team, the PM, the tech lead, the designer and any key result owner from outside the trio. Managers and stakeholders read the written update instead of attending.

## Sources

- [Google re:Work: Set goals with OKRs](https://rework.withgoogle.com/intl/en/guides/set-goals-with-okrs)
- [What Matters: Google's OKR Playbook](https://www.whatmatters.com/resources/google-okr-playbook)
- [What Matters: OKR Scoring Step-by-Step Guide, How to Grade Your OKRs](https://www.whatmatters.com/faqs/how-to-grade-okrs)
- [What Matters: How to End the OKR Cycle, Grading, Reflecting, and Improving](https://www.whatmatters.com/okrs-explained/grading-okrs)
- [What Matters: Grading vs. Reflecting on OKRs](https://www.whatmatters.com/faqs/grading-and-reflecting-on-okrs-whats-the-difference)
- [What Matters: Why we don't grade OKRs weekly](https://www.whatmatters.com/faqs/weekly-okr-grading-check-in)
- [What Matters: Why You Should Divorce Compensation From OKRs (Laszlo Bock)](https://www.whatmatters.com/articles/laszlo-bock-divorce-compensation-from-okrs)
- [What Matters: Should You Connect OKRs and Compensation? (Ryan Panchadsaram)](https://www.whatmatters.com/articles/should-you-connect-okrs-and-compensation-spoiler-alert-no)

## How this guide was made

Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.