Search
Close this search box.
Search
Close this search box.
Search
Close this search box.

Organizing around Outcomes with OKRs and Scrum

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp

Aligning Scrum Team Topology to Strategy with OKRs and Product Goals

Yeah, I know. Could I squeeze more buzzwords into the title? I guess I could include Digital Transformation, Cloud, AI, and Machine Learning for effect. But seriously, I wanted to share some insights around how to align your Scrum Teams to your strategy leveraging OKRs and Product Goals. 

Driving Change Using OKRs 

We maintain performance by tracking the health of Key Performance Indicators(KPIs). We use Objectives and Key Results (OKRs) to drive performance change. Objectives point towards the desired state. Key results measure progress towards that desired state. This performance change could be about our product or the ability to innovate/create that product. (Gap between realized and unrealized value/ability to innovate in evidence-based management (EBM) terms) By setting OKRs we’re typically setting our sights on a complex problem – the space where Scrum and Empiricism thrive. 

Achieving OKRs using Empiricism and Scrum

Working in self-managed empowered multi-disciplinary teams using fast feedback loops is a great way to tackle complex problems. 

This is true regardless of how much IT or technology is involved. We might have an OKR that requires business change involving mainly legal, marketing, procurement, HR, and so on, which would still benefit from using Scrum’s empirical team-based approach. 

For example, if a healthcare provider is aiming to digitize their patient journey to streamline it and make it more efficient, part of that will be to implement an electronic medical records system (EMR). But the objective isn’t just about implementing an IT system. It’s a change in the operating model. The organization supports this change through the development of new procedures, systems, and capabilities. 

Focusing on Outcomes rather than Outputs

OKRs and Scrum are both designed to focus on outcomes over outputs. Most agile practitioners would recognize the N from “INVEST in User Stories” which stands for creating Negotiable user stories that provide optionality/flexibility for learning about what’s the best way to achieve outcomes. Having said that, most agile practitioners do feel like user stories are a form of requirements – meaning they are required. 

Actually, user stories, any other form of Product Backlog Items, and even the Sprint Goal should be considered options – meaning they are optional. We currently think they are valuable, but we might learn of more valuable things to focus on. 

Even the Product Goal is just an option. Maybe there we will find a better Product Goal for the Scrum Team to rally around or maybe there’s another better Goal that requires a different team topology. 

Be Agile about your OKRs

Similarly, OKRs reflect the strategic direction at a certain point in time. We might learn something that would suggest a change in the Key Results or even the Objective itself. The frequent transparency provided by sprinting towards an OKR enhances the empiricism that might drive these realizations and is an enabler for strategic agility.

Many organizations fail to see this perspective. They consider OKRs as if they’re set in stone. 

The same sort of time, budget, and scope-oriented project management mindset that is hampering so many agile teams is affecting OKR implementations as well. 

The problem with activity/output-based OKRs

Many OKR practitioners struggle to figure out how to break an annual strategy/OKR into meaningful outcome-oriented quarterly OKRs. By default, they break the big outcome into implementation steps a.k.a activity/output/milestone OKRs. It’s the project management mindset again – we basically bring in the classic work breakdown structure (WBS) into the OKR framework. 

Going back to the patient journey digitization effort. Many organizations would define an initial OKR of choosing an EMR system. This is an example of an activity. It doesn’t deliver business value on its own. Once we set this OKR it’s harder to think of alternatives that might obviate the need for an EMR system in order to achieve the desired outcomes.

We’ve seen it happen countless times on agile teams struggling to slice stories in a meaningful manner and not sure how to come up with a useful Increment at the end of a short Sprint.

When working with OKRs we can leverage the same techniques that help these agile teams identify valuable partial outcomes that enable us to inspect and adapt our tactical and strategic direction. 

Organizing Around OKRs

Another common reason why we see output-based OKRs is the team topology. 

We often see organizations defining OKRs and then mapping them to their existing teams. In this example, this will mean cascading OKRs throughout different IT and business functions. The cascaded OKR grows farther and farther away from the desired Outcome because functions/silos can’t deliver these outcomes. They can only deliver outputs. Hence, the prevalence of Output-based OKRs. 

After we define these OKRs the different functions will, of course, try to collaborate but we know how hard it is to collaborate effectively across functions. And with each group focused on an output-based OKR, we lose the opportunity to align around outcomes and are back to managing “projects”. This might work fine for some OKRs. But some OKRs are simply too complex to successfully achieve this way. 

OKR-Driven Team Topology

A better approach might be to consider the level of complexity each OKR exists in. Then, create focused cross-functional Scrum Teams around the most complex OKRs. You might call this “OKR Driven Team Topology”. 

Each one of these teams would focus on an OKR and have that as their Product Goal. Their Product Owner would have ownership of the OKR. This team would be THE team to talk to about this OKR. 

If an OKR requires more people than would fit one Scrum Team consider forming a Nexus (or any other agile team of teams structure) around this Product Goal. Or maybe you can split the Objective and have separate Scrum Teams working on each Key Result (KR). There are multiple possible topologies.

The key point is to try and keep the outcome orientation all the way to the trenches where people work to create usable valuable Increments. In your Sprint Review, Inspect the Increments created with an eye toward your OKR. Adapting might mean changing tactics of how to achieve the OKR or even changing the Key Result or the Objective itself. 

OKRs and Focus

The approach I laid out above is the ultimate way to achieve focus on one strategic outcome. 

Realistically, not all OKRs would map 1:1 to a team or Nexus. And that’s ok. For example, you might have 20% of your most complex/critical OKRs handled using dedicated teams with the rest of them mapped to existing teams/functions. 

If that’s the approach you’re taking, make sure you’re limiting the amount of OKRs that map to each team in each time period. For example, set an “OKR in Process” limit of 3 per team per quarter. And when a team hits the limit, don’t set the OKR for this quarter. This will drive a tough but important conversation about priorities. But it will set the teams and therefore the organization for a better chance to actually deliver on the strategic outcomes that matter the most. 

Having 3 OKRs per quarter that you actually achieve is much better than 6 OKRs per quarter that drag on from quarter to quarter. 

NOTE: You might find it useful to start tracking flow metrics (WIP, Flow/Cycle time, Throughput, Aging) as they relate to your OKRs… 

When to organize around outcomes with OKRs and Scrum

In this article, we explored the relationship between OKRs, Scrum, the teams’ topology, and outcome/output-oriented OKRs (and teams!).

A key step in accelerating agility is to continuously assess whether you’re optimally organized around value. OKRs can provide a very useful lens to use for this assessment. 

This is the time of the year when many of you are drafting your annual OKRs. Take this opportunity to consider whether your current team topology (in IT/technology and beyond!) is well-positioned to achieve these OKRs. 

Another opportunity to use this lens is If you’re currently trying to figure out what your Scrum team topology should look like (e.g. when starting your agile journey, extending or accelerating it). Considering your strategic focus via OKRs is a great perspective to consider in this process. 

A discussion about Strategy/OKRs and how they map to team topology is now a core part of my conversations with clients and our implementation strategy workshops. 

Are you trying to figure out how to connect OKRs and Scrum in a way that organizes around outcomes? Feel free to reach out and we can discuss how I might be able to help. 

Want more info about our OKR Coaching and Training Offerings?

Subscribe for Email Updates:

Categories:

Tags:

Lean Startup
Agile Product Ownership
The Agile Coach
Rapid RTC
RSA
ARTs
Risk Management in Kanban
Continuous Integration
Scrum and XP
Agile in the Enterprise
Kaizen Workshop
Slides
Agile Basics
Professional Scrum with Kanban
Continuous Planning
ALM Tools
lean agile change management
Business Agility
Agile Testing Practices
Agile Community
Achieve Business Agility
Agile Games
GanttBan
Product Ownership
Process Improvement
Agile for Embedded Systems
Portfolio for Jira
Value Streams
Lean Software Development
Agile Development
Games and Exercises
Agile Exercises
Agile Release Planning
Keith Sawyer
Nexus
LAB
SAFe
Risk-aware Product Development
Sprint Iteration
Agile Project Management
Scrum With Kanban
Risk Management on Agile Projects
Agile Mindset
Principles of Lean-Agile Leadership
RTE
Continuous Deployment
Planning
Lean Agile Leadership
Agile Israel Events
Nexus Integration Team
Covid19
Frameworks
Agile Marketing
Jira Plans
Lean Budgeting
Amdocs
Certified SAFe
Artificial Intelligence
Certification
Continuous Improvement
AgileSparks
System Integration Environments
Agile Assembly Architecture
Applying Agile Methodology
Agile Delivery
Effective Agile Retrospectives
A Kanban System for Software Engineering
Scrum.org
IT Operations
Introduction to ATDD
Legacy Enterprise
Jira
Entrepreneurial Operating System®
DevOps
Nexus vs SAFe
SAFe DevOps
Quality Assurance
Tools
Kanban Basics
An Appreciative Retrospective
chatgpt
POPM
Daily Scrum
Managing Risk on Agile Projects
ART Success
Self-organization
System Team
EOS®
Lean Risk Management
Nexus and SAFe
Perfection Game
Agility
Agile Contracts Best Practices
Limiting Work in Progress
Systems Thinking
Lean Agile
PI Planning
Elastic Leadership
Agile Outsourcing
Scrum Guide
Coaching Agile Teams
Agile Program
Lean-Agile Software Development
Tips
Reading List
ATDD
Presentation
Jira admin
Lean and Agile Principles and Practices
TDD
Story Slicing
Release Train Engineer
BDD
Software Development Estimation
Change Management
Scrum Master
LeSS
Lean Agile Organization
Jira Cloud
Kanban 101
Scrum
Engineering Practices
Software Development
NIT
Professional Scrum Master
Manage Budget Creation
Professional Scrum Product Owner
AI Artificial Intelligence
Large Scale Scrum
Lean Agile Management
Sprint Retrospectives
QA
Agile Product Development
The Kanban Method
Lean and Agile Techniques
ATDD vs. BDD
Scrum Values
SA
AI
Video
Kanban
Accelerate Value Delivery At Scale
Implementation of Lean and Agile
Development Value Streams
Implementing SAFe
RTE Role
Legacy Code
Built-In Quality
Team Flow
Scrum Master Role
Enterprise DevOps
Agile
Test Driven Development
LPM
predictability
WIP
Iterative Incremental Development
Acceptance Test-Driven Development
Scrum Primer
Lean-Agile Budgeting
speed @ scale
Advanced Roadmaps
Continuous Delivery
Agile Techniques
Product Management
Spotify
Atlaassian
Agile Games and Exercises
Agile Project
SAFe Release Planning
User stories
What Is Kanban
ROI
speed at scale
Scaled Agile Framework
Releases Using Lean
Kaizen
Hybrid Work
Introduction to Test Driven Development
PI Objectives
Agile India
Agile and DevOps Journey
ScrumMaster Tales
Agile Risk Management
Kanban Game
agileisrael
Nexus and Kanban
Atlassian
System Archetypes
Kanban Kickstart Example
Lean Agile Basics
Sprint Planning
Operational Value Stream
Webinar
Code
Managing Projects
Agile Release Management
Agile Israel
Program Increment
SPC
AgileSparks
Logo
Enable registration in settings - general

Contact Us

Request for additional information and prices

AgileSparks Newsletter

Subscribe to our newsletter, and stay updated on the latest Agile news and events

This website uses Cookies to provide a better experience
Shopping cart