Organizing around Outcomes with OKRs and Scrum

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 thoughts on how to align your Scrum Teams to your strategy using OKRs and Product Goals.

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 toward the desired state. Key results measure progress toward that desired state. This performance change could be about our product or the ability to innovate and create that product, which is the gap between realized and unrealized value in evidence-based management terms. By setting OKRs, we’re typically setting our sights on a complex problem - the space where Scrum and empiricism thrive.

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, that would still benefit from using Scrum’s empirical team-based approach.

For example, if a health care 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 by the development of new procedures, systems, and capabilities.

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 and flexibility for learning about 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. 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 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.

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 toward an OKR enhances the empiricism that might drive these realizations and enables strategic agility. Many organizations fail to see this perspective. They consider OKRs as if they’re set in stone. The same time, budget, and scope-oriented project management mindset that hampers so many agile teams affects OKR implementations as well.

Many OKR practitioners struggle to figure out how to break an annual strategy or OKR into meaningful outcome-oriented quarterly OKRs. By default, they break the big outcome into implementation steps, also known as activity, output, or milestone OKRs. It’s the project management mindset again - we basically bring 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 activity. It doesn’t deliver business value on its own. Once we set this OKR, it’s harder to think of alternatives that might remove the need for an EMR system while still achieving the desired outcomes. We’ve seen this 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 use the same techniques that help agile teams identify valuable partial outcomes that enable us to inspect and adapt our tactical and strategic direction.

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 and 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.

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 another 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. There are multiple possible topologies. The key point is to 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 with an eye toward your OKR. Adapting might mean changing tactics, the Key Result, or even the Objective itself.

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 or critical OKRs handled using dedicated teams, with the rest mapped to existing teams and functions. If that’s the approach you’re taking, limit the number of OKRs that map to each team in each time period. For example, set an “OKR in Process” limit of three 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 gives teams and the organization a better chance to actually deliver on the strategic outcomes that matter most. Having three OKRs per quarter that you actually achieve is much better than six OKRs per quarter that drag on from quarter to quarter. You might also find it useful to start tracking flow metrics, such as WIP, flow/cycle time, throughput, and aging, as they relate to your OKRs.

In this article, we explored the relationship between OKRs, Scrum, team topology, and outcome/output-oriented OKRs. A key step in accelerating agility is to continuously assess whether you’re optimally organized around value. OKRs can provide a very useful lens for this assessment. If you’re drafting annual OKRs, take the opportunity to consider whether your current team topology, in IT/technology and beyond, is well-positioned to achieve them. Another opportunity to use this lens is when you’re trying to figure out what your Scrum team topology should look like, whether you are starting, extending, or accelerating your agile journey. 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.

OKRs work best when they are connected to how teams actually operate. Explore OKR advisory or let’s talk.