OKRs with Scrum

I'm working in a company that has been using OKRs for a relatively short time, and I had no prior experience working with them before joining; so we're still finding our way towards using them effectively.

Do you have any insight into how OKRs currently translate into work team members are expected to do, how that work is made transparent, and how value is accounted for?

Do you have any insight into how OKRs currently translate into work team members are expected to do, how that work is made transparent, and how value is accounted for?

Based on what I've read about OKRs, our key results are too much like tasks, and should instead be measurable outcomes; so for me that's a known limitation in relation to accounting for value.

Key results are currently viewed in a traffic light system to indicate likelihood of being achieved. I have read that it should usually be possible to measure them in percentage terms.

The objectives are set around the expected "problem" a Scrum Team will solve over a quarter. 

In terms of transparency, the OKRs are visible to the whole company in the form of a shared spreadsheet (but I'm not sure how often team members look at that). I think management are doing a good job of keeping attention on the OKRs in general.

The Product Owners are very conscious of the OKRs, and so they manage their Product Backlogs accordingly.

The OKRs are discussed at least every Sprint Review, and my advice to the Product Owners has been to explain decisions and progress in the context of OKRs and to explain how achieving / not achieving the Sprint Goal represents such progress.

The OKRs are discussed at least every Sprint Review, and my advice to the Product Owners has been to explain decisions and progress in the context of OKRs and to explain how achieving / not achieving the Sprint Goal represents such progress.

The implication seems to be that those behind the OKRs ought to be managed by the Product Owner as stakeholders. That sounds fine. But from the little I've read about OKRs, I wonder if they might also impact wider quality considerations. These considerations could include an organizational Definition of Done that does not yet exist or which Product Owners may not fully have sight of.

Yep! 

I use ORK with Scrum here in my cia. We actually make okr's our sprint goal :) 

It's cool 

Although not exactly equal, for the Scrum team that just started using OKRs, I usually explain this way:

Objectives: outcome, goal

Key Results: output, ToDos, features/tasks

For example, one of the goals of this Sprint is to complete a flexible member login features.

Key Results may include:

• Allows customers to sign up for accounts and logins
• A feature that allows customers to sign in with their Google Account
• A feature that allows customers to log in using their FB account
• ...

Or, the goal of this Sprint is to complete the membership system. 

Then Key Results might include:

• Flexible member login function
• Client Area
• Member Management
• ...

When they are familiar, they will spontaneously apply OKRs to other aspects.

For example, The Objective is to improve product quality 

Key Results may include: 

• Increase unit test coverage from 80% to 90%
• Customer satisfaction increased to 80%
• The number of defects reported by customers must be reduced to three or less
• ...

The implication seems to be that those behind the OKRs ought to be managed by the Product Owner as stakeholders. 

I think that's a reasonable way of looking at it. In our case, management play a large role in setting the OKRs, and we would probably consider them stakeholders.

But from the little I've read about OKRs, I wonder if they might also impact wider quality considerations. These considerations could include an organizational Definition of Done that does not yet exist or which Product Owners may not fully have sight of.

Please can you explain the impact on quality, because I don't see the connection. Whilst we are working towards achieving things, the Development Teams are made aware that they are responsible for safeguarding quality.

Historically, "Done" wasn't well understood, but we created our first organizational Definition of "Done" a few days ago. I ensured developers wrote it, based on what they consider reasonable/achievable quality expectations of Product Owners and stakeholders. 

@Thiago, @Ching-Pei, you mention using OKRs for the Sprint Goal. I can imagine that is a useful technique, but from what I've read, OKRs are normally set over a longer time period, e.g. a quarter or a year. For us, they're set quarterly.

It's actually the use of such long term objectives that I see as a potential risk to agility, if they aren't used well.

Objectives: outcome, goal

Key Results: output, ToDos, features/tasks

Ching-Pei, I have seen a different explanation of OKRs.

I am generally wary of framework definitions from companies that sell tooling, but what you call key results, are actually described as "Initiatives" by Perdoo: https://www.perdoo.com/okr/ and it seems common for key results to be described as measurable outcomes. e.g. http://okrexamples.co/product_management-okr-examples

Yes,  OKRs are normally set over a longer time period, e.g. a quarter or a year.

But you can also apply it to different timelines.

The Objectives can be ambitious, but the Key Results must be quantifiable that clearly make the objective achievable.

Applying OKRs to the Scrum Framework makes it easier to understand through short period of a Sprint.

However, your question should be biased towards management.

OKRs can be set at the company, team and personal levels and may be shared across the organization. 

As a Scrum Master, what do you think your team can accomplish, strengthen, and improve this quarter?

Set the Objective. For example, improve customer satisfaction.

And How?

Key results:

• ...
• ...
• ...

Through OKR , teams define the Objectives that the team(s) are aligned to. The key results bind one or more measures to this objective through Key results. 

This Key result is not supposed to be output (or number of functionality delivered) , but the outcome / value that the organisation would gain through the objective. 

So let us say that, we have a objective to achieve 100000 million users by Q1 2019 , that provides a direction to the teams and definitely the product owners to be aligned and prioritize the features that go into for that timeframe.

The release/sprint objectives could be derived from the OKR too as earlier mentioned, however it will be only a subset of the objective that can be met.

Therefore OKR is meant to give a clear direction to the teams . The timeboxes within that timeframe will be partially or fully aligned to one or more OKR measures.

It is also my understanding and practice that business OKRs are aimed at longer periods of time. As long as they aren't dictated by management, but discussed and negotiated with the responsible parties (those acountable to be more precise), the risks of getting derailed are reduced. 

One key topic that needs to be agreed beforehand (or updated prior to activities) is how do you interpret results. Full transparency (and common sense) should lead, on a case by case scenario. I've seen situations where 60% and above was considered success, and others where less than 90% was deemed failure.

Hey Simon,

As I was researching OKRs, I've run into your post. Here are some links that I found useful for OKR:

https://www.cio.com/article/3302036/okr-objectives-and-key-results-defined.html

https://firstround.com/review/How-to-Make-OKRs-Actually-Work-at-Your-Startup/

https://www.businessinsider.com/googles-ranking-system-okr-2014-1

https://corvisio.com/resources/what-is-okr/

https://www.castsoftware.com/blog/20-software-engineering-and-code-quality-goals-you-should-nail-before-2018

https://medium.com/productcamp/product-planning-with-okrs-objectives-key-results-660708675e96

Hi all, 

my humble contribution from my experience would be the following.

OBJECTIVE/S represent the end goal (sprint Goal) What you are trying to achieve.

KEY RESULTS are in essence measurable Milestones that serve the realization of the Objective/s.

INITIATIVES are the tasks that are needed to be undertaken to achieve the Key Results.

Example.

OBJECTIVE: Improved Communication

KEY RESULTS: A) from 50% to 90% grammar accuracy for emails and messages sent. B) Reduce the unstructured messages sent from 99% to 25%

INITIATIVES: A1) Install software that checks your grammar while you are writing. A2) Perform a grammar check before send any email via automated functionality. B1) Provide a template to be used for all the Critical messages. B2) Allow only spreadsheet files to be attached to emails.

Let me have your feedback,

Thanks and good day.

Hey Simon,  

You have brought up quite an interesting topic for discussion. Whenever anything that has to do with the Scrum comes up, I cannot resist myself looking at the game of Rugby, at least for my own understanding. 

With respect to OKRs, let's assume our team is playing in a Rugby championship. 

Here the Objective would be to win the Cup/Title. 

and Key Results would be Wins. In addition to these larger Objectives and Key Results, there are several other factors that can determine the well trained, well-equiped winning team.

There might be several other results our team management wants to achieve. Let's say they are points difference, the number of tries each game, level of fatigue in the team, consistency, possession, versatility, collective mental and (physical) strength in case of an adverse situation. These values do contribute to the win for an individual game and the whole championship. As a Scrum Master, you are most likely to assume the role of the coach of the team. Hence, keeping up these factors becomes essential for you for one individual game and for winning the championship. The stakeholders may be equivalent to the team management, as they could be looking at some historical data, have additional intelligence on your opponent teams, vision to look beyond the present team (no matter if they win or lose) and continue fostering the game of Rugby in their jurisdiction etc. 

I might be wrong but what Ian suggested, 

But from the little I've read about OKRs, I wonder if they might also impact wider quality considerations.

we might be able to understand this through the game of Rugby. What if the team is highly dependent on a few (one or two) players while others are not supporting the play? Can that team win? What happens if these players are injured or given a red-card? Can the team still win games against strong teams when they are out of shape? Can the team still win if they have not correctly measured their opponents or unable to read their opponents? 

I think OKRs can be a great tool to identify, inspect and adopt these wider aspects (other than just goal deliver). A team may be able to deliver the Product Goals consistently but that does not mean that they will always be able to deliver Organizational goals.

It would be helpful to go through the paper by Takeuchi and Nonaka titled "The new new product development game" and Ken and Jeff's 1995 paper.

Thanks 

We follow OKR methodology in our organization for different departments.

You can check out these articles for complete details on OKR & also with templates for various departments. 

https://www.keka.com/how-to-implement-okr-framework/

For templates of various departments, you can check the same blog for everything about OKR.

https://www.keka.com/marketing-okr-examples/

https://www.keka.com/research-and-development-okr-examples/

https://www.keka.com/sales-okr-examples/

I have recently joined a company which uses OKRs and mine is a new project and team. So I have a very basic question. Who is involved in creating OKRs? Do Scrum Master play a role in defining OKR or just helps team to define the Key results?

Who in the company has decided that OKRs are an appropriate technique for this product?

Here are my thoughts on OKR's and how I am trying to apply them on my Scrum Teams

Objectives: Align with the Product Vision and/or Product Goal. Something that is lofty and may take longer than a quarter.

Key Results: Value that you expect to deliver that quarter. These can become Sprint Goals, or Sprint Goals can be increments to achieving a Key Result.

Love to others thoughts on this approach. 

Thank you @Ching-Pei Li for your contribution in this post. I learn a way to start and understand OKR successfully.

Dear all with respect 

Iam leading  project using hybrid approach between scrum and Kanban for chromic diseases control in primary health care center , we also used the OKRs mostly for quarterly  basis 

we think we still in premature phase and the key advantage of OKR is  the mind set rather than methodology 

is there any one has an idea about using OKR in Health , or OKR& scrum in health

my e-mail for further communication  hatim73@gmail.com  

thanks