OKR and Scrum - how to connect two powerful frameworks

We receive a lot of questions at Perdoo about how to use OKR with other frameworks for managing people, processes, and activities in organizations. One of the most popular among companies who build software, like us, is Scrum; a software development framework that’s been around since the 90’s and one we’ve used internally.

The benefits of Scrum and why it beats Waterfall

The biggest benefit of Scrum over other traditional frameworks like Waterfall is its focus on short, incremental sprints, and adaptability to change.

With Waterfall, outcomes are defined and agreed upon at the beginning of the project, often with a detailed scope and project spec. A plan is derived from these specs by working back from a point of completion in the future, with time, budget and dependencies worked out in a linear fashion. The product of this approach is a roadmap that outlines all the software development work that needs to be completed up to the point of release. The downside? If anything changes along the journey, timelines, dependencies, and often budgets need to be completely reworked; the plan effectively breaks.

Scrum, on the other hand, is concerned with short incremental sprints toward a desired endpoint. Detailed plans are replaced with lean specs or “stories” and regular retrospectives which measure the outcome of each sprint. Those retrospectives should answer the question, “has the work we’ve done moved us closer to our desired story.”

Scrum’s power comes from its ability to manage work toward an unknown, unique, or never attempted outcome. The framework systematically and incrementally manages the process of solving a problem that’s never been solved before. Waterfall, in contrast, works best when processes and work involved are predictable and have been attempted before.

It’s the difference between building a bridge and a rocket ship.

Rocket technology is relatively new, building a rocket ship takes several incremental steps and iterations to get right. The work that lead to SpaceX landing a rocket on a ship is a great example.

Bridge construction, on the other hand, is a very well-understood engineering challenge that has been solved numerous times. Building a bridge is low on iteration, high on time and cost planning, and this is where Waterfall is often used.

How do OKR and Scrum compare?

OKR and Scrum are similar in that both frameworks need a person dedicated to their implementation, a “Scrum Master” or an “OKR Ambassador”. Scrum is more known for its implementation by product teams though product evangelicals are also ascribing to OKR as well. Both have clearly defined roles, and their responsibility is to ensure teams stick to the frameworks. Scrum is a highly prescriptive framework with specific roles and ceremonies. The benefits of Scrum include transparency, project visibility, and constant communication. The team collectively decides what work they can complete in short 2-week “sprints” which makes scrum a very democratic process.

OKR also has a set of rules, although not as codified as Scrum. Those rules determine what an Objective can be, what Key Results are, and how they work together to measure the achievement of goals. Like Scrum, OKR has timeframes, however, these are a lot longer (quarterly and yearly) than two-week sprints. Creating OKRs involves first, company leadership deciding what they want to achieve, then teams creating their own OKRs and aligning them to the goals of the company.

How to combine Scrum with OKR

OKR and Scrum can and do work together quite successfully as long as everyone is clear about the scope and parameters of each framework. The OKR methodology we use at Perdoo includes Initiatives, the things that teams work on to achieve their Objectives. Sprints fit nicely with Initiatives to work within a quarterly cycle for Group OKRs.

To make these two frameworks fit, it’s important that when beginning each quarter, an OKR Ambassador and a Scrum Master sit together with the development team to decide the 3 most important things that need to be achieved that quarter. Since OKR deals with longer timelines and broader goals, and Sprint with the more granular organization of work, OKRs should come first.

For OKR to work correctly at this stage, it’s important to stress the need for Key Results that measure outcomes, not output. Measuring the number of bugs squashed, for example, is a bad Key Result if the problem you’re looking to solve is buggy software. Fixing a bug may reduce bugs by one, but if more bugs are reported, you’re not actually making the software less buggy, you’re just counting how many you fix.

A better Key Result would be to measure bugs reported or support tickets raised during a quarter. If this metric trends down, you can be pretty confident you’re fixing the problem you set out to solve.

With Objectives and Key Results set, the business of Sprint planning can begin. The length of Sprints is important to decide at this stage. If Sprints are monthly, a single Sprint Goal will likely correspond directly to one of the development teams’ 3 Objectives. For shorter sprints of 2 weeks, which are more common, Sprint Goals become the Initiatives of Objectives.

The second approach is recommended as it connects the two frameworks while maintaining their original purpose, with Sprint Managing the production and shipping of code and OKR setting the goals and measuring the outcome of work. This also means, however, that each OKR requires its own Sprint timeline. This works well if you have a large development team working on different areas of a product like front-end, back-end, and sys-admin. With this approach, each area leads 1 OKR and 1 Sprint timeline, while the whole group owns 3 OKRs between them. For smaller dev teams who don’t have the capacity to run 3 Sprint timelines, we recommend using this approach but sticking to a single OKR.

Long story short

Scrum and OKR do play together and work well in a software tool like Perdoo where Sprint Goals become Initiatives for OKRs. However, to see real value from both frameworks it’s vital that they’re well understood by everyone involved, that time is set aside to manage them, and that a Scrum Master and an OKR Ambassador are nominated.