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.
This article (slightly changed) was first published on Gtmhub Blog on 11.03.2021. 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.
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.
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.
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.
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. It is not a status update meeting.
Vision: Become the best online shop for travel gadgets.
Focus NOW: Let’s focus on conversations in our checkout process
Product Goal = Objective: We observe churn mostly during Phase A and B. We want to re-design it so that our customers will love it.
Key Results: How will we know that they love it? How will we know if we’re getting there?
Key Result 1: Most of the customers churn when they are need to create an account for our shop. Let’s enable 3rd party login and 30% of our customers use it.
Key Result 2: Customers love the new checkout process so much that 40% return within 4 weeks.
Key Result 3: Churn Rate in Touchpoint X is too high. Let’s reduce it by 10%.
At the end of the OKR Cycle, which means after ~6-8 Sprints, 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 itself. What works well? What not? Generate ideas to improve the process 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?