Combining OKRs with Scrum
At VRT, we are constantly looking to improve how we work together. As long time adopters of Agile & Scrum, we have matured the way team members work together significantly. But making teams work together has proven to be a challenge.
One recent addition to our toolbox in that regard has been the usage of OKRs. This framework; popularized by the book ‘ Measure What Matters’ by John Doerr; promises to improve inter-team coöperation by making department/team/individual objectives more transparent. This should allow for more focus, engagement & alignment.
At present, it is too early for us to evaluate if these benefits are being reached on an organization level, but we have good hopes. Starting to work with the OKR framework has made it clear that it mixes quite well with an Agile/Scrum way of working, and that using OKRs also has benefits on the team level.
This post is aimed foremost towards Scrum teams interested in, or already working with OKRs. In what follows I describe my approach to combining OKRs and Scrum for better team results. It is in no way ‘the best possible’ approach. Rather, it is an approach that seems to make sense to me at this point in time. By sharing this, I hope some people will be triggered to share their insights on this matter. And maybe this can give other teams some inspiration to do their own experiments with Scrum and OKRs.
I assume the reader has some grasp of what Scrum and OKRs are, this post is not intended as an introduction to these frameworks. For more information about OKRs, I have already mentioned Doerr’s book, (much) more on scrum can be found on the scrum.org website.
Getting started
OKRs were introduced in our department at VRT during the (start of the yearly) budgetting cycle as an alternate way to define the desired outcomes (Objectives) of the development teams and make them more concrete without it turning into a discussion about ‘feature shopping lists’.
Next, we defined an OKR playbook describing how we want to use a quarterly cycle to (re)define & work towards OKRs based on the google playbook.
After defining the OKRs some more steps need to be taken to mesh the OKRs in the day-to-day working of the team so that it’s full potential can be unleashed.
1/ Defining OKRs
The first step in working with OKRs is defining them. There are lots of do’s and don’t that could be rehashed here when discussing the creation of ‘good’ OKRs, but I will refer to this existing post describing the basics of the OKR framework as this is not the main topic in this post.
A good practice when doing OKRs in an Agile/Scrum environment, is involving as many stakeholders as conveniently possible, taking care to avoid analysis paralasis. At least include the (whole) team & some business stakeholders when (co-)creating the OKRs. The Product Owner is accountable for making sure they get created but is not required to do all of the creating himself. Getting more people involved will greatly improve the quality of the OKRs (as multiple viewpoints are incorporated) and also contribute to the teams common understanding of what they are about.
This excercise is a great time for all of the stakeholders to re-evaluate the ‘product vision’ in terms of what impact we want to generate with our product(s).
After everyone has chipped into the creation process, the Product Owner will typically be the person with the final say about how the OKRs should be prioritized and which will be selected for the upcoming period (Quarter in our case).
2/ Aligning product backlog and OKRs
Because of their nature, most Objectives or Key Results make poor backlog items. An OKR says what you want to achieve, but it typically doesn’t tell you anything about how to achieve it.
The Objective should be an answer to the question ‘where do we want to go’ while the Key-Results are typically ‘milestones’ that indicate that you are moving in the right direction. In most cases, both will allow for multiple concrete actions that can be taken to actually achieve them.
In what follows, we will call a backlog item that is aimed at furthering along an OKR an ‘initiative’. After having selected the OKRs to focus on, the backlog can be searched for ‘initiatives’, being ideas that may move us closer to completing the Objective or a Key Result. Of course, new initiatives can be added as well.
Also important is the realization that some features/stories on top of the list may appear to serve no OKR. This is where the ‘focus’ aspect of the OKRs comes in play as this gives the Product Owner a big indication that this may not be the right time to invest in that particular feature/story.
3/ Work towards realizing OKRs
As said before, an OKR specifies where we want to go (direction). It says very little about how this should be achieved. In most cases, in complex situations, it is also unclear how best to reach such an objective. The typical ‘Agile’ answer to move forward under these uncertain circumstances is to use PDCA cycles (Plan-Do-Check-Act) to iteratively bring us closer to our desired goal by running ‘experiments’. And that is exactly what a sprint should be all about.
Every ‘initiative’ can (should) be seen as an experiment. During sprint planning, we should try to select those initiatives that we assume have the best chance of helping us achieve the OKRs. After having selected a collection of initiatives that the team believes are achievable in the upcoming sprint, we try to predict what the effect will be on our OKR scoring if we achieve them.
Those estimated changes in OKR scoring can then be used as the ‘sprint goal’. Setting the sprint goal in this way sidesteps the common pitfall of having a ‘checklist’ as a sprint goal (aka our goal is to complete all these loose tasks) and it allows for the team to adapt during the sprint if they uncover better ways of achieving those desired outcomes.
Doing this covers the Plan portion of PDCA, obviously the Do part is actually running the sprint. During the sprint, the ‘sprint goal’ which is comprised of a subset of the OKRs can act as a ‘northern star’ guiding the team when issues arise and adjustments need to be made.
4/ Make OKRs first class citizens of Review & Retrospective meetings
At the end of the sprint, successful completion of the ‘sprint goal’ is evaluated during the Review meeting. This is a great time to (re-)score the OKRs and evaluate if they have been sufficiently achieved or still need extra work. (Incidently this is the Check portion of PDCA).
Finally, the ‘Act’ is conducted when the team will reflect on the sprint ; its results ; and how they were (or weren’t) achieved during the retrospective meeting. This meeting can also surface improvement opportunities with regards to the OKRs and how the team is working with them. They could conclude that they are too stretchy (or not enough) or that certain Key Results are not really helping the Objective and may need changing, or….
Closing thoughts
We are still learning to use OKRs effectively. It will probably take some time for the benefits of increased focus, alignment and engagement to become apparent. It is however clear that the framework is a good addition to Scrum as it addresses the problem of translating a vision into clear mid-term direction for the team. Something which the Scrum guide is less clear on.
Thinking about OKRs as the direction in which to go (a goal) and backlog items as experiments that may or may not move us closer to said goal makes both frameworks highly compatible & complementary.
