Why and how to combine OKRs with Scrum?

Cansel Sörgens has worked for over 12 years for E-Business / E-Commerce companies, applying agile practices. Today, as OKR Coach and Trainer at cansel-soergens.com, she guides individuals, teams and organizations in their journey to their goals. In this Voices of OKR piece Cansel shows how SCRUM and OKRs can work together.

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 easier of their customers or users. 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.

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.

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 rather abstract product vision more tangible. If a team wants to make the product goal even more tangible and measurable, then I’d recommend going for OKR.

OKR Definition: Every 1-4 months (depending on the pace of the organization) the team and other involved people can write an OKR set that manifests the direction and focus for the next period of time.

In case there is 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. It depends strongly on how the teams are organized and how the OKR set is written though.

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

Sprint Review > OKR Check-in: After each sprint the team can observe the outcome, the movement in the Key Results. If there isn’t any, what could be the reason? Should the team re-think their approach in the next sprint? Maybe experiment in other aspects? OKR Check-In meetings are a time for these kinds of conversations to take place. They are not status update meetings.

OKR Review: At the end of the OKR Cycle, which means after many Sprints, it is time to reflect on what happened. All the involved people can evaluate their progress made in Key Results.

  • Which outcomes have been reached?
  • Have we accomplished the Objective? 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?

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

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 = Objective: We observe churn mostly between Phase A and B. We want to re-design it so that our customers will love it.

How will we know that they love it? How will we know if we’re getting there?

1. Key Result: Most of the customers churn when they need to create an account for our shop. Let’s enable 3rd party login and we know that they like it because 30% of our customers use it.

Backlog Items: Enable Google Login, Enable Apple Login.

2. Key Result: Customers love the new checkout process so much that 40% return within 4 weeks.

Backlog Items: Analyse behaviour of returning customers, make an attractive offer/reason to return.

3. Key Result: Churn Rate in Touchpoint X is too high. Let’s reduce it by 10%.

Backlog Items: Understand why customers churn (ask for feedback, interviews, etc.), redesign touchpoint X,  A/B Test it.


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.

OKR Retro: Last but not least, at the end of the OKR Cycle have a retrospective regarding the process itself. What works well? What not? Generate ideas to improve the process along the way.

The monthly online OKR Lean Coffee I have co-founded might be helpful to discuss your challenges with other like-minded practitioners. Keep in mind: it is not about perfection, it’s about progress.  

Looking to get started with OKRs? Try Gtmhub FREE for 7 days!

Comments

Join the discussion

Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments