Objectives and key results (OKRs) is a simple tool to create measurable goals for agile teams. It provides a framework for defining objectives, how teams will achieve those outcomes, and tracking their progress. It’s a light-touch way of setting goals and focus. It was originally developed by Andy Grove at Intel and has since been adopted by other product organisations such as Google, LinkedIn, Twitter and Uber.

Here’s how we use OKRs on GOV.UK, the UK government’s website. Teams are trusted to deliver value for users, and this framework reduces tension between agile delivery professionals and senior management.

What is an objective?

An objective is a bold and qualitative goal that the company or organisation wants to achieve. For example, ‘Prepare the GOV.UK platform for the scale demands of Brexit’ or ‘Make it easier for users to start using our product’. It’s best that they’re ambitious, not easy to achieve or audacious in nature; they are not sales targets. These objectives make up your product strategy.1

Objectives are usually set by the CEO or Head of Product and set the direction for the company or programme. Objectives shouldn’t be dictatorial goals, they should be missions that every team member can buy in to and get behind. Because they’re ambitious, it’s not healthy to set deadlines for when a product team should achieve an objective. Since CEOs aren’t on the frontlines, they can’t accurately say how long it will take a team to reach a goal.

Objectives may be put on a roadmap and make up part of an organisation’s strategy for getting nearer to its vision.

What is a key result?

A key result is a tangible and quantitative goal for how a product team will achieve an objective. For example ‘Benchmark the speed and reliability of the publishing pipeline, improve it by 10%’ or ‘10% of new users will publish a document within 5 days of creating an account’. There may be one or many key results that contribute towards achieving an objective. It’s best that they’re specific, measurable, achievable and realistic, to help a team answer the questions ‘How will we reach the objective?’ and ‘How will we know when we’re done?’

Key results are usually set by the product team which helps them be objective about the scope and prioritisation of their goals. Teams shouldn’t be beholden to accomplishing a key result by a deadline or by a certain amount; they are not quotas, key deliverables or a list of tasks. Key results are lines in the sand that teams can reach in a healthy way, by not burning out. It’s possible to change a key result later down the line, and some teams often will as they get closer to understanding the problem. Since teams are on the frontlines, they’ll often be able to set more realistic key results as they mature.

Key results are often made up of lots of little initiatives, epics to be pulled into sprints or a series of experiments to reach a goal.

What do OKRs look like?

A template OKR slide

We use the OKR template above to set objectives and key results for product teams on GOV.UK. You can copy this open slide deck to use with your team.

How to use OKRs in practice

When a product team starts a new mission, we add the objective to the template. We get together as a team and ask ourselves ‘What does success look like?’ This produces a set discovery and delivery goals2 to be reached, which usually shape our key results. Since the key results have been produced and agreed collectively by every team member, we have a shared view of how we’ll achieve the objective.

Every fortnight a product team will meet with the GOV.UK programme team – senior management for the platform – and report on how they’re progressing. It’s also an opportunity to raise any risks they’ve come across or anything they need from the programme team. Meetings are light-touch and only take 30 minutes. Product teams have more time to spend solving problems, and the programme team can offer help where it’s needed.

The GOV.UK programme team may take the opportunity to set new objectives each quarter. It’s sensible to take a temperature check of work underway at regular intervals, in case there are new priorities. This also gives product teams a chance to play back to management their findings from a discovery, which means that some times the objective set is based entirely on the team’s work.

Reporting confidence and progress

Product teams will report how confident they feel in being able to achieve the objective, and teams will also report their progress in the discovery or delivery threads of their work. It’s a ‘finger in the air’ score to give the programme team a sense of how well they’re progressing. By taking this reading fortnightly, the programme team can see when confidence drops or progress halts, which is an opportunity for them to help the team remove blockers.

It’s a good idea to check the team’s confidence during a sprint retrospective. You can work out the team’s progress by counting how many cards on the sprint board have been done and how many are left to do. It’s a simple method, and it’s OK for you to create more cards after some discovery work – that’s agile!

Why use OKRs?

What’s great about OKRs is that they pull top-down leadership together with bottom-up knowledge workers, giving them a space to communicate and reach a shared vision. They help everyone move together in the right direction, creating alignment between product teams in an organisation. It requires a shift in mindset from outputs to outcomes. Teams can understand how they’re contributing to the organisation’s strategy, and leadership can better set realistic short-term goals. Product teams are inspired and empowered to deliver value in interesting ways, and leadership can foster a culture of determination, boldness and psychological safety.

Setting OKRs can expose some discomfort and issues you might not have encountered before. But that’s a good thing, and working through problems brings people closer together. OKRs are an empowerment technique to give product teams clear problems to solve and the space to solve them.

OKRs are not an instant solution, nor are they designed to create perfect unity. Instead, they give space for leadership to set ambitious goals that teams can buy into, and the framework gives space for product teams to solve problems in creative ways.

Thanks for reading! Don’t hesitate to reach out with any questions on Twitter or LinkedIn, and let me know if there’s anything else which would be helpful.

  1. After writing this post, someone reached out to me and asked ‘What if all the objectives are too grand and unattainable?’ to which we found out that their leadership didn’t have a product strategy. If objectives are not clear or can’t realistically be worked on, this is a fault of leadership. I’ll write a little more on what to do about that soon. ↩

  2. A few people have asked me whether they should set and report key results in the discovery phase for a new product or service, and I’d say no. Discoveries are projects in which you explore ideas and gather information to help you decide what to deliver. You might have a set of key tasks to do in a discovery, but the only key result is having a better idea for what to do next. ↩