In my previous blog post I write about how the OKR Process works. But what about if there is already another process / framework (e.g. Scrum) the team works with? If we work with Scrum, do we still need OKRs? Why? How can we combine our Scrum process with OKR? Again, is it really necessary? I get these questions a lot.

If you understand German you might enjoy this podcast episode of Scrum Meistern with Ralf Kruse (26.01.2021).

If you understand Turkish you might enjoy my talk in Flow Conference Istanbul (11.12.2020).

---

In all these years I’ve worked for/with Scrum Teams, one common problem I’ve observed was that most of the teams didn’t see the big picture. No matter how hard the management tried to communicate the vision and strategy of the company, there was still a huge gap between vision and strategy and the work the teams delivered. Almost nobody had an understanding if and how they’ve contributed to the success of the company.

How can OKRs close this gap?

Most Scrum Teams are unfortunately turned into “Feature Factories” who deliver a feature and start developing the next one. They don’t pause to reflect and analyze if the feature really solved a problem or made the life of their customers or users easier. The question about the outcome of their output remains unanswered.

If the team and organization want to escape from the feature factory, and remain aligned but still autonomous instead, outcome-oriented OKRs could help.

How do OKR and Scrum work together?

I’m personally very happy about the new addition of “Product Goal” in the Scrum Guide 2020. Product Goal helps the teams to make their probably rather abstract product vision more tangible. If a team wants to make the product goal tangible and measurable then I’d recommend to do so in form of OKR. 

A product goal written in the form of an OKR, derived from company objectives, can help the team to focus on the most important thing for now. After the delivery the team can analyse the outcome by observing the progress made in Key Results (as described in the Scrum Guide “progress towards goals”). The key is, of course, to write measurable outcomes. Depending on the information they gather on the way, the team can re-define their approach and activities they do in sprints.

OKR Planning

Every 3-4 months (depending on the pace of the team/organisation) the team and involved people can write an OKR set, that manifests the direction and focus for the next period of time. 

In case there are more than one team working on the same (sub)product, it is not necessary to write an OKR set per Team. Each team can contribute by focusing on different Key Results. Though, it depends strongly on how the teams are organised and how the OKR set is written.

Product Backlog: Based on the OKR set, the team can identify which experiments, activities, features, initiatives, etc. would help to move towards their goal. This will also make the decision making progress much more easier.

Sprint Review > OKR Check-in

After each sprint the team can observe their outcome, the movement in the Key Results. If there isn’t any, what could be the reason? Should the team maybe re-think their approach? Maybe experiment on other aspects? OKR Check-Ins are for these kinds of conversations take place in the OKR Check-Ins.

An example might help to understand it better. 

Vision: Become the best online shop for travel gadgets.

Focus NOW: Let’s focus on conversions in our checkout process

Product Goal = OKR

• Objective: Customer love our new “accountless” checkout process.
  1. Key Result 1: 30% of customers login via 3rd party (G, FB, A).
     • Backlog Items: Enable Google Login, Enable Apple Login.
  2. Key Result 2: 40% of customers w/o account buy again within 4 weeks.
     • Backlog Items: Analyse behaviour of returning customers, make an attractive offer/reason to return.
  3. Key Result 3: Conversion rate in Touchpoint X is increased by 10%.
     • Backlog Items: Understand why customers churn (ask for feedback, interviews, etc.), redesign touchpoint X, AB test it.

OKR Reflection

At the end of the OKR Cycle, (6x 2 weeks sprints = 12 weeks) it is now time to reflect on what happened? All the involved people can evaluate their progress made in Key Results. Which outcomes have been reached? What about the Objective? Have we accomplished the Objective itself indeed? If not, why not? Have we chosen the right Key Results at all? Have the circumstances changed? Is the goal still relevant today? What do we learn of it? What should we do differently in the next iteration?

Also have a retrospective regarding the process and team work itself. What works well? What not? Generate ideas to improve the collaboration along the way.

With all these learnings the team can now start the next OKR Cycle by writing a new or adjusted set of OKRs.

---

The scrum teams I’ve worked with found the combination of OKR & Scrum very helpful as they had much more clarity and transparency about their focus and sprint goals. Also reviewing their outcomes after the sprints gave them a sense of contributing to something bigger and started thinking with the end in mind.

Thinking in outcomes is not easy but crucial to make OKRs work. Most probably you won’t write the perfect outcome-oriented measurable goals. But that is ok, give it time. Also keep in mind: It is not about the perfection, it is about the progress and learning along the way.

Have you combined OKR & Scrum? What are your experiences?