OKRs and Scrum: How They Work Together

Many organisations use OKRs to set direction and Scrum to deliver products. The two can reinforce each other, or they can clash, with quarterly OKRs turning into fixed plans that undermine Scrum's empiricism. This guide explains how OKRs and Scrum fit together, how to map objectives and key results onto the Product Goal and Sprint Goals, how to use key results in Scrum events, and the pitfalls to avoid.

Key takeaways

• The Scrum Guide does not mention OKRs; OKRs complement Scrum rather than replacing any part of it.
• Organisational objectives can inform the Product Goal, and key results can show whether the product is creating the intended outcomes.
• Sprint Goals are the steps a Scrum Team takes toward the Product Goal, and can be chosen to move key results.
• Initiatives that support OKRs belong in the Product Backlog, ordered by the Product Owner.
• OKRs should never become a fixed plan that prevents the team from adapting.

What the Scrum Guide says

The Scrum Guide does not mention OKRs. It defines Scrum's accountabilities, events, artifacts and commitments, including the Product Goal, the long-term objective for the Scrum Team, and the Sprint Goal, the single objective for each Sprint. It also describes Scrum as founded on empiricism: decisions based on what is observed. Any use of OKRs alongside Scrum should respect these foundations. For background, see Product Goal and Sprint Goal explained and our complete OKR guide.

How OKRs and Scrum map together

OKR concept	Scrum concept	How they connect
Organisational objective	Product Goal	The objective can inform the Product Goal, the long-term objective for the product
Key results	Measures of product outcomes	Key results show whether the product is moving toward the objective
Quarterly cycle	Several Sprints	A quarter contains around six two-week Sprints, each with its own Sprint Goal
Initiatives	Product Backlog items	Work expected to move key results is ordered in the Product Backlog
Weekly check-ins	Sprint Review and inspection	Progress on key results is inspected with stakeholders

The mapping does not need to be perfect. What matters is that the team understands why its work matters and can see whether it is making a difference.

Who decides what

• Leaders usually set a few organisational objectives that express strategy.
• The Product Owner, working with stakeholders and the team, proposes how the product can contribute, often through the Product Goal and product-level key results. According to the Scrum Guide, the Product Owner is accountable for the Product Goal and the order of the Product Backlog, and the organisation must respect their decisions.
• The whole Scrum Team defines each Sprint Goal in Sprint Planning.
• The Developers decide how to do the work.
• The Scrum Master helps the organisation and team use OKRs without undermining Scrum.

If OKRs are used to dictate the contents of every Sprint from above, the Product Owner's accountability and the team's self-management are undermined.

Using key results in Scrum events

Sprint Planning

The Product Owner can propose a Sprint Goal that is expected to move a key result, for example "Simplify the payment step so more new customers complete onboarding." The key result gives context for why the Sprint is valuable, but the Sprint Goal remains a single, clear objective for the Sprint.

Daily Scrum

The Daily Scrum focuses on progress toward the Sprint Goal, not on OKRs. Keep it that way.

Sprint Review

The Sprint Review is an excellent place to look at key results with stakeholders: what changed in the numbers since the last Sprint, what the team learned, and whether the Product Backlog should change as a result. See the five Scrum events explained.

Sprint Retrospective

Key results about how the team works, such as cycle time or release frequency, can inform Retrospective discussions about improvement.

A worked example: one quarter

As an illustration, an e-commerce company sets the organisational objective "Delight first-time customers." A product team's Product Goal is "First-time buyers can find, buy and receive their order without needing help." For the quarter, the team agrees key results with stakeholders:

• Increase first-purchase conversion from 3.0% to 3.8%
• Reduce first-order support contacts by 30%

Over six Sprints, Sprint Goals might include:

1. "Find out why first-time visitors abandon their basket."
2. "First-time buyers can check out as a guest."
3. "Delivery options and costs are clear before checkout."
4. "Customers get proactive delivery updates, so they do not need to ask."
5. "Fix the three most common first-order problems reported to support."
6. "Test a simpler product page with a small group of visitors."

At each Sprint Review, the team and stakeholders look at the key results and adjust the Product Backlog. When the third Sprint shows little effect on conversion, the team shifts focus to delivery updates, which data suggests is a bigger driver of support contacts. The OKRs set the direction; Scrum lets the team learn how to get there.

The Scrum Master's part

The Scrum Master is accountable for the Scrum Team's effectiveness and, according to the Scrum Guide, helps the wider organisation understand and apply Scrum. With OKRs, that often means helping leaders write outcome-focused key results, coaching the Product Owner on connecting OKRs to the Product Goal, facilitating conversations when OKRs threaten to become fixed plans, and helping the team use key results to inform Sprint Reviews and Retrospectives.

OKRs for several teams on one product

When several Scrum Teams work on one product, they share one Product Owner, one Product Backlog and one Product Goal, according to the Scrum Guide. Product-level OKRs should usually be shared too, so that all teams pull in the same direction. Each team then sets its own Sprint Goals, coordinated so they contribute to the shared key results. See how to lead multiple Scrum Teams.

Handling change mid-quarter

Scrum expects change: the Product Backlog is updated as the team and stakeholders learn. OKRs should allow the same. If evidence shows an initiative is not moving a key result, change the initiative. If circumstances change so much that a key result no longer makes sense, update or drop it openly and explain why. Pretending an outdated OKR is still relevant does more harm than admitting it has changed.

Key results versus Sprint Goals

	Key results	Sprint Goal
Time horizon	Usually a quarter	One Sprint
What it describes	A measurable outcome	The single objective for the Sprint
Who sets it	Leaders, Product Owner and stakeholders, often with the team	The whole Scrum Team in Sprint Planning
Part of Scrum?	No	Yes, the commitment for the Sprint Backlog

Signs OKRs and Scrum are working well together

• The team can explain how its Sprint Goals connect to key results.
• Key results are reviewed with stakeholders at Sprint Reviews.
• The Product Backlog changes when evidence shows an approach is not working.
• The Product Owner's decisions are respected, not overridden by OKRs.
• Teams focus on a few key results rather than many.

A Sprint Review agenda that includes OKRs

As an illustration, a one-hour Sprint Review for a team working toward quarterly key results might run like this:

1. Five minutes: the Product Owner restates the Product Goal, the current key results and the Sprint Goal.
2. Twenty minutes: the team shows what was done, with stakeholders trying the product where possible.
3. Ten minutes: the team shares the latest key result figures and what changed since the last Sprint.
4. Twenty minutes: stakeholders and the team discuss what they learned and what to do next.
5. Five minutes: the Product Owner summarises likely changes to the Product Backlog.

Product Goal versus quarterly OKR: an example

A Product Goal can outlast several quarters, while OKRs usually change each quarter. For example, a Product Goal of "Customers can manage their whole insurance policy online, without calling us" might take a year or more. In the first quarter, the key results might focus on online policy changes; in the second, on online claims. Each quarter's OKRs are a step toward the same Product Goal, which changes only when it is fulfilled or abandoned.

Questions for Product Owners when OKRs arrive

• Which organisational objective does our product contribute to most?
• Do these key results describe outcomes our product can realistically influence?
• What in our current Product Backlog should move up or down as a result?
• What are we explicitly not doing this quarter?
• How will we show progress at Sprint Reviews?

Common pitfalls

• OKRs as a fixed plan: treating initiatives agreed at the start of the quarter as unchangeable undermines empiricism.
• Output key results: "Deliver features A, B and C" turns OKRs into a scope commitment.
• Too many OKRs per team: competing key results pull Sprints in different directions.
• Separate OKRs for teams on one product: teams sharing a product share one Product Backlog and one Product Goal, so product-level OKRs should be shared too.
• Replacing Sprint Goals with OKRs: Scrum still needs a Sprint Goal every Sprint.
• Changing the Product Goal every quarter by default: the Product Goal changes when it is fulfilled or abandoned, not simply because a new quarter starts.
• Bypassing the Product Owner: OKRs should inform product decisions, not take them away from the Product Owner.

OKRs with Kanban teams

Teams using Kanban without Sprints can use OKRs in a similar way: key results set direction, initiatives are ordered in the team's backlog, and regular reviews inspect progress. Flow measures such as cycle time and throughput can also make useful key results for improving delivery. See our complete Kanban guide.

Getting started

1. Agree a few organisational objectives.
2. With each Product Owner, connect them to Product Goals and product-level key results.
3. Put initiatives into the Product Backlog and let the Product Owner order them.
4. Use key results to inform Sprint Goals and to inspect progress at Sprint Reviews.
5. Review how OKRs and Scrum are working together at the end of the quarter, and adapt.

Learn more

For writing OKRs, see how to write good OKRs. Scrum Agile OKR Plus covers using OKRs with agile teams; it includes self-paced training and an online exam on ExamVault by CertExpert with three attempts included, and the certificate and digital badge are valid for two years. For the Product Owner's accountability, see our complete Product Owner guide.