Succeeding with OKRs in Agile
from Allan Kelly


OKRs are about goals bigger than the next story. OKRs prioritize purpose and strategy over backlogs. Objectives are big goals; key results are smaller goals that build towards the objective.
Does your agile team get lead astray by burning fires? Do you struggle to keep your agile team focused?


Succeeding with OKRs in Agile infographic
succeeding with okrs in agile.pdf
High Resolution infographic


Short Quick lessons

  • Bottom up
    • Don't impose OKRs from above
    • Don't set OKRs top-down
  • Organization
    • OKRs are a team sport
  • True north
    • Use OKRs to guide and fight to stay on course
    • Don't stick blindly to OKRs as the world around changes
  • Leaders
    • Build psychological safety / make failure an option
    • Make completely clear what the organization's priorities are
  • Reviewing
    • Ask questions as :
      • How does this create value ?
      • How will this be measured ?
      • Are these goals ambitious enough ?
      • Are the goals too ambitious ?
  • Team
    • Make the team responsible for setting their own OKRs and delivering them
  • Money
    • Do not link OKRs to bonuses and remuneration

Introducing OKR

  • OKRs = Objectives and key results
    • Objectives are Big Goals
    • Key results are smaller goals that build towards the objective
  • Goals bring focus
    • Focus is powerful
  • OKRs = "Test Driven Management"
    • Decide what you want (Objective)
    • Next set a series of acceptance criteria : key results
    • Get on and develop
    • Don't consider yourself done until you can pass the tests and meet the objectives
  • Dissecting OKRs
    • OKR is something you and your team wish to achieve
    • Good OKRs are outcome-focused
      • Not about measuring progress towards a goal
      • Are all about delivering outcomes that add value
    • Each result should be useful in and of itself
  • An objective should have its own wholeness that is more than the sum of its parts
    • Whole objective should create more value than simply the value of the Key Results added together
  • OKRs get reviewed at the end of each quarter
  • The real benefit is in the outcomes delivered
  • Ambition over estimation
    • The aim of OKR
      • Not to do everything
      • The aim is to be ambitious (push further)
    • Teams are not normally expected to complete 100% of their OKRs
      • 70% is more common
    • With OKRs teams are encouraged to aim high
      • Not impossibly high
      • BUT high enough to be challenged

Why Use OKRs

  • 3 reasons why OKRs work well with an agile approach
    • Fill a need at the mid-term planning level
    • OKRs are essentially a test-first approach
    • OKRs enhance communication
  • Mid-term planning
    • Glue between the short-term daily / sprint planning and long-term plans
  • Test-Driven OKRs
    • Each Objective has a set of Key Results
    • Each of these Key Results is a test
      • Has the result been achieved
      • Each Key Result should be measurable
    • Test first approach
      • Creates focus
      • Tells you when to stop
        • Stop when the tests pass
  • Communication
    • Easier to communicate what a team is doing
    • A means of communicating status and progress
    • Success motivates continuation
Some things are more important than OKRs and sometimes those things can't be measured.

OKR History

  • Management by Objective - Peter Drucker (1992)
    • Managers decide strategic objectives
    • Effort & Resources
  • OKR - Andy Grove at Intel
    • Extended MBO with a focus on delivery
What and How
Quarterly or monthly
Private and siloed
Public and transparent
Bottom-up or sideways
Tied to compensation
Mostly divorce from compensation
Agressive and aspirational

Outcomes, value and benefits

  • Outcomes should be things in their own right
    • Not proxies for something else
  • Outcomes should benefit customers
  • Value and benefit are synonous
    • People tend to associate 'value' with a number
    • Benefits fits more easily when talking non financial value


Value comes in many different forms
  • Learning is valuable
    • Knowledge on new tech for example
  • Feedback is valuable
    • Extend our existing knowledge
  • Risk reduction is valuable
    • Increases the probability of delivering value
  • Money
    • "Money is the best form of feedback"


  • Taking a board-level 'stakeholder-value' approach to value
    • Rather than a narrow 'shareholder' value view
  • Grow the pie so that there is more for all
  • Compelling evidence that pursing a larger pie for all
    • creates non financial value
    • benefits society
    • brings financial rewards too

Writing OKRs

  • Quarterly writing of new OKRs is a strategy question :
    • What are the strategic priorities for the next quarter ?
    • What does the team aim to do ?
    • What targets will the team set for itself ?
  • Prioritization is not just about deciding what to do
    • It is also deciding what not to do
    • Everything that is not in the OKRs is lower priority (by definition)
  • OKRs operate within a cycle : prioritize, focus, execute, review

Team setting

  • Are you setting utility OKRs or aspirational OKRs ?
    • One team may embrace ambition and aim high
    • Other teams may value predictability and set goals they are confident can be achieved
  • Mark aspirations
    • Some teams mark objectives or key results that they feel to be aspirational

Limited number

  • Aim of OKR = create focus
    • Self-defeating to set too many OKRs
  • Teams exist to share work
    • TowarD a common purpose
    • OKRs serve to provide that purpose
  • OKRs serve to help say "NO"
    • At least "Not Now"
  • 3 is the maximum (Allan's recommendation)
    • This rule of thumb serves both for the number of O and the numbers of KRs


  • All OKRs are not equals
    • Some might be higher priority
  • Possible to prioritize Key Results independently of objectives
    • Example : KR1 of O1, KR1 of O2, KR2 and KR3 of O1, ...
    • Warning : it complicates matter


  • In sprint or days per OKR
  • Priority does not correspond to the capacity allocated

When to Set OKRs ?

  • No specific time to set them
  • Should not be set weeks and weeks in advance of the quarter they will apply
  • Just a few weeks :
    • 2 or 3 should be fine

Not Money

Profit is a side effect of delivering on that purpose and creating value


  • First thing to write = Objective
    • Something the organization wants / values
    • Something that contributes towards the bigger goals that leaders have outlined
  • The thing you are trying to achieve
    • Perhaps the thing you are trying to build / create
    • A change you are seeking to make
  • The objective doesn't need to explain the problem in detail
  • Make the value the objective brings obvious
    • Example :
      • Retool the delivery pipeline to facilitate CD
      • VS Increase ROI by reducing TTM with a new delivery pipeline and continuous delivery practices
    • Use the "so that"
  • Avoid boxing yourself into a specific approach or solution
One OKR for the team per quarter : nominated by the team to increase productive capacity
  • Testing trouble : time
    • Some OKR can be measured after a specific amount of time
    • Can be marked as achieved
    • Final judgement for a later date

Key Results

  • Deliver value with each KR
  • Fight against dominos
    • Don't accept dependencies
  • Test-driven
    • KRs are the tests against which the objective will be measured
    • Example :
      • Make the site easy to use OR The site is secured
      • Turn into testable statements
      • New users can complete a purchase on the site within 5 minutes without cursing

KR tricks

  • Experiments
    • Phrasing a key result as an experiment can be a useful way of attempting something with an uncertain outcome
      • Exemple : Run 3 experiments to increase page views
    • Success is doing the experiment itself and absorbing the learning
    • Like this it makes safer for the team to take on risk
  • Hypothesis-driven development
    • Template
    • Outcome of those KRs = learning
  • Time-boxed
    • Experiment for 4 weeks for example
  • Survey
    • Make changes to people
    • Test it with a survey

Organizing to deliver OKRs

  • 2 schools :
    • OKRs are additives
      • Add more work
      • A new way of injecting work
    • OKRs are everything
      • OKRs = origin of all work and all organization
  • OKRs everywhere
    • "Will this contribute to achieve the OKR?"
  • Sprint planning with OKRs
    • Planning meeting needs to include a full review of the current OKRs
    • Direct the team to the highest prio OKR
    • Avoid the temptation to do a little of everything

Traffic lights and status

Not started
On course
No more work needed
Problems encounter
Team has accepted the goal will not be achieved

OKRs and backlog

  • 2 approaches :
    • Backlog first
    • OKRs first
      • Success
        • No longer burning down the backlog
        • Delivering OKRs
      • Choose Sprint Backlog items derived from the OKRs
        • Might be KRs themselves


  • Problematic in an OKR driven world
    • Does not generate new business benefit
  • Option 1 : suppress BAU
    • Force BAU to go away
  • Option 2 : reduce or remove BAU
    • Set an OKR to reduce BAU
    • Think about google
      • Community support portal for example
  • Option 3 : make BAU better
    • Make the work better
      • More efficient with better quality
  • Option 4 : Objective 0
    • BAU in the OKRs
    • Objective 0 -> keep the existing system operation within the historic range
    • Add a 4th OKR for BAU here

Beyond the quarter

  • 3 horizons in terms of planning :
    • Now : sprint planning looks a few weeks into the future
    • Soon : OKRs look to the next few months
    • Later : looking months and years into the future
      • Can create valuable learning
        • Don't expect plans not to change
        • What if thinking
OKRs form a link between the big and possibly nebulous strategy and the specific-code face work of agile teams
  • Don't forget technology
    • Technical excellence and consistently high quality = key strategy for agile teams
    • Technical liabilities over technical debt
      • Better metaphor
        • Debt has a good side (buy houses, ...)


  • They need to set the context of work through culture, big goals and strategy elements
  • They need to embody and live the culture as role models for the teams
  • They can promote behaviors and decisions in line with the culture
  • It is the myriad of tiny daily decisions that managers make that bring culture, goals, strategy into being


  • OKRs require supportive culture
    • Psychological safety
      • Failures will happen
      • "if you aren't failing, you aren't trying"
  • Delivery culture
    • Culture needs to value delivery
    • Not hours worked, not partially done work
    • Delivery = actual working products being used by actual customers


  • Utility mode vs aspirational mode


Don't link remuneration to OKR outcomes
  • Once money is attached to OKRs
    • People feel compelled to chase 100% success
      • Easiest way = reduce the target
  • Look at employee behavior instead
    • What behaviors would you like from your team members ?
    • What kind of behavior makes work go more smoothly ?
As with agile, you need to find you own way to OKRs [...] be prepared to experiment.
Last modified 6mo ago