OKRs and Scrum: How Objectives and Key Results Work Together

Objectives and Key Results (OKRs) and Scrum are two of the most widely adopted frameworks in modern product and technology organisations -- and two of the most frequently misconnected. Teams run OKR planning cycles and Scrum ceremonies in parallel with little intentional linkage between them, producing the peculiar situation where everyone is aligned on the quarterly objective in theory and misaligned on sprint priorities in practice.

Getting the connection right requires understanding what each framework is actually for and where the natural integration points lie.

What OKRs Are

OKRs consist of two elements: Objectives and Key Results. Objectives are ambitious, qualitative descriptions of a desired future state -- they answer the question "where do we want to go?" Key Results are measurable outcomes that indicate progress toward the Objective -- they answer the question "how will we know we are getting there?"

The distinction between Key Results and tasks is critical and frequently blurred in practice. Key Results describe outcomes (user retention increased by 15 percent, onboarding completion rate above 80 percent); tasks describe activities (build the new onboarding flow, fix the email reminder). A Key Result that reads like a task -- "ship the new onboarding module" -- is a warning sign that the OKR has been confused with a delivery plan.

How OKRs Align with Scrum

The natural integration point between OKRs and Scrum is the Sprint Goal. In Scrum, the Sprint Goal is a single objective that provides coherence to the Sprint -- it answers the question "why are we doing this Sprint?" When Sprint Goals are derived from OKRs, backlog prioritisation becomes more objective: items that contribute to current Sprint Goals and current OKRs move to the top; items that do not, regardless of their internal appeal, move down.

This connection also addresses one of the most common Scrum dysfunctions: Sprints that are a collection of loosely related items rather than a coherent unit of work with a clear purpose. An OKR-derived Sprint Goal provides that purpose.

The Cadence Question

Most organisations run OKRs on a quarterly cadence (13 weeks) and Scrum on two-week Sprints. This means a single quarter contains approximately six Sprints. The question of how to connect them is partly about planning and partly about tolerance for change.

A practical approach: at the start of each quarter, the product owner and team review the new OKRs and identify which backlog items most directly support them. Sprint Goals for the first one or two Sprints of the quarter are planned with reasonable confidence; later Sprints are left more open, with the expectation that learning from early Sprints will inform what comes next. This respects the empirical nature of Scrum while providing enough directional alignment to make OKRs meaningful.

Common Misuses of OKRs in a Scrum Context

1. Treating Key Results as a task list. When a team writes KRs like "complete API documentation" or "launch beta to 50 users," they are describing outputs, not outcomes. The framework loses its value -- you can complete all the tasks and still miss the underlying objective.

2. Cascading OKRs so rigidly that teams lose autonomy. OKRs work best when teams have meaningful input into their own objectives. Cascading from company to business unit to team to individual, with each level simply translating the level above, produces compliance rather than commitment -- and compliance produces mediocre results.

3. Setting too many Key Results. Three to five Key Results per Objective is a widely recommended range. More than that and the OKR becomes an unwieldy checklist rather than a focused signal of what matters most.

4. Grading OKRs as performance reviews. OKRs are meant to set ambitious targets -- the standard guidance is that consistently achieving 100 percent of your OKRs means you are setting them too low. Tying OKR attainment directly to performance ratings or compensation destroys the ambition that makes the framework valuable.

5. Ignoring OKRs during Sprint Reviews. The Sprint Review is the ideal moment to connect Sprint outputs to OKR progress. Are the Key Results moving in the right direction? What does the evidence from this Sprint tell us about our chances of hitting the Objective by quarter end?

Practical Setup

Organisations getting started with OKRs in a Scrum environment benefit from keeping the initial setup simple. Start with one Objective per team per quarter, with three Key Results. Use Sprint Reviews to check OKR progress explicitly. Build the habit of writing Sprint Goals that reference the current OKR before adding complexity.

The most important thing is that the connection between OKRs and Sprint work is made deliberately and explicitly -- not assumed. When that connection is clear, teams operate with both directional coherence and the operational flexibility that Scrum provides. When it is absent, both frameworks underperform.

XNM Consulting helps organisations build Scrum and agile delivery practices that connect operational execution to strategic objectives.