When you want to achieve something, anything, your desires are based on a preferred outcome. It’s a very simple, basic human concept developed at an early age. One way of putting it into a sentence is:
I will ________ as measured by ____________”
This is how John Doerr explained objectives and key results (OKR) in his book Measure what Matters . While it’s a simple concept, the business world is a complex place with many moving parts. Still, by adhering to simple principles, big results can manifest.
Wat is OKR?
The acronym OKR stands for Objectives and Key Results, a popular goal management framework that helps companies implement and execute strategy. The benefits of the framework include a better focus on results that matter, increased transparency, and better (strategic) alignment. OKR achieves this by organizing employees and the work they do around achieving common Objectives.
An OKR consists of an Objective, which tells you where to go, and several Key Results, which are the results you need to achieve to get to your Objective. Initiatives are all the projects and tasks that will help you achieve your Key Results.
The framework includes a number of rules which help employees prioritize, align, and measure the outcome of their efforts. OKR helps companies bridge the gap between strategy and execution and move from an output- to an outcome-based approach to work.
A brief history of OKR
OKR has a long history that can be traced back to 1954 when Peter Drucker invented MBO or Management by Objectives . In 1968, Andrew Grove co-founded Intel and — while CEO at Intel — he further developed MBO into the OKR framework as we know it today. In 1974, John Doerr joined Intel and learned OKR during his time there. Doerr went on to join Kleiner Perkins Caufield & Byers — one of the first major investors in Google — and became an adviser to Google in its very early days. Doer introduced OKR to Google’s founders, Larry Page and Sergey Brin, who then implemented OKR at Google (which still uses it today).
The Benefits of OKR
Current research shows that when comparing groups of employees who used OKR against those that don’t, those that used it proved much more effective at their jobs, resulting in better performance and increased sales. In fact, the group who didn’t use OKR actively asked to be involved in the process in future cycles. A full rundown of the ROI of Goal Management can be found here .
The biggest impact of using OKR in most organizations without goal management already in place, is a cultural shift from output to outcomes. OKR creates focus, accountability, transparency , and alignment within an organization. The results of all this is an increase in performance and employee engagement.
What is an Objective?
An Objective is a description of something that you’d like to achieve in the future. An Objective sets the direction — like a destination on a map. Objectives shouldn’t be technical and shouldn’t contain a metric, so that everyone understands where to go.
“Where do I want to go?”
An Objective describes where you want to go and sets a clear direction. Think of it as a point on a map, a destination like New York.
What is a Key Result?
A Key Result is a measurable outcome required to achieve the Objective. It contains a metric with a start and target value. Key Results measure progress towards the Objective — like a signpost that shows how close you are to your Objective.
“How do I know if I’m getting there?”
A Key Result shows you how you’re progressing towards your Objective. Think of it as a signpost with a distance marker.
What is an Initiative?
Initiatives are all the projects and tasks that will help you achieve a Key Result. Imagine your organization is a car. The Objective is your destination, the Key Results show if you’re heading in the right direction, and the Initiatives are what you’ll do to get your car moving.
“What will I do to get there?”
An Initiative describes what you’ll do to achieve your Key Results. Think of it as a description of what you’ll do to get to your destination.
OKR and Srum? Yes!
On 18.11.2020 Ken Schwaber and Jeff Sutherland jointly presented the updated Scrum Guide 2020 . After reading the new guide I have the feeling that Scrum has returned to its roots. Scrum has come home to what it always wanted to be, but hasn’t been for a long time: an agile framework! Scrum’s coming home!
Why should you bother with the Scrum Guide at all?
Scrum is established and has become a sensational success. Are there still people at all who have not heard of Scrum? And does a revision of the Scrum Guide affect daily practice at all?
These are questions I have also asked myself and I have come to the answer: the new Scrum Guide has meaning. The Americans would say: It matters!
Agile work is now so strongly influenced by Scrum that agile work is often mistakenly equated with Scrum. At the same time, there are clear weaknesses in the Scrum process that has been practised so far, some of which I have already described in my article “The agile speed lie”. From my point of view, Scrum has taken a last big development step with the new Scrum Guide 2020. A step that brings Scrum back closer to the family of agile frameworks. If the training of future Scrum Masters is based on the new Scrum Guide 2020, it will be a blessing both for the topic of agile work and for the teams involved.
Agile work is now so strongly influenced by Scrum that agile work is often mistakenly equated with Scrum. At the same time, there are clear weaknesses in the Scrum process that has been practised so far. From my point of view, Scrum has taken a last big development step with the new Scrum Guide 2020. A step that brings Scrum back closer to the family of agile frameworks. If the training of future Scrum Masters is based on the new Scrum Guide 2020, it will be a blessing both for the topic of agile work and for the teams involved.
Why, What and How – The Three Levels of Work Organisation
The Why, What & How of the new guide reads as if Simon Sinek’s Golden Circle has now also arrived in Scrum.
What is it about? In the past, the Scrum framework was almost exclusively concerned with the “what” and the “how“. With the backlog and sprint planning, the product owner was responsible for the “what“, i.e. what work had to be done. The development team took care of the “how“, i.e. the form of completion. The “why“, i.e. the reason why things should be done in the first place, was completely left out. Prioritisation in the backlog was done via business value, an abstract concept that was often no help in daily work. Worse, instead I know very many teams where prioritisation was done by effort.
Until now, the product vision was a loose bracket for the backlog. The product vision represents a rough description of the product to be developed and was actually only mentioned in a subordinate sentence in the Scrum Guide until the 2017 version:
“The increment is a step towards a vision or goal”
In the Scrum Guide 2020, there is now a hierarchy of meaning that runs through the entire document and is particularly addressed in sprint planning, the heart of the Scrum process: The Why, The What and The How.
The “why” and the commitment to a product goal
The top level of the “why” is the newly introduced product goal. The product goal is now obligatory for the Scrum process. The new Scrum Guide writes about the Product Goal:
“Product goal: The product goal describes a future state of the product that can serve the Scrum team as a basis for planning. The product goal is located in the product backlog. The rest of the product backlog defines what the product goal will accomplish.”
This means that the backlog is no longer a collection of all possible requirements, but only contains points that “pay in” to the product goal. Dave West1, who apparently worked on the new Scrum Guide, writes in his blog post on the product goal:
“The word “goal” is intentional because it describes two things:
It is something to strive for, and it is measurable when achieved.”
This is exactly the goal definition that makes a good OKR: a direction and a measurable description of what goal achievement looks like.
Why does the product target matter so much to me? Let’s face it, it doesn’t matter what the team velocity is. It also doesn’t matter what great and cool features the team has worked on from the backlog. The work can be completely worthless if the answer to the only important question is missing at the end:
What is the benefit for the customer?
I have sorely missed this question of “why” in Scrum so far. This is exactly the reason why the Lean and OKR expert Felipe Castro has long described the Scrum framework as Agile for delivery teams. So far, unfortunately, he has been right about that.
I believe that in the future, if Scrum is lived properly, the product goal will become the most important artefact2 in the Scrum process.
The sprint goal: There can only be one
At the sprint level, the sprint goal has also been strengthened. Until the 2017 version, the sprint goal was more of a rationalisation of the content of the sprint planning. This means that along with the sprint planning content, a sprint goal should also be set by the team.
Unfortunately, I found that I saw very few really good sprint goals in the wild. Either, and unfortunately this was the majority, there were no sprint goals at all or there were directly quite a few for a sprint. Neither one nor the other was helpful.
With the new Scrum Guide 2020, the sprint goal guides the work in the sprint. The Scrum team works out the Sprint Goal together and is responsible for the fulfilment of the Sprint Goal. We are finally getting out of the treadmill of the ticket processing machine that Scrum was often known for in practice.
Consistently thought through to the end, it means: It doesn’t really matter which things are worked on in the sprint, the main thing is that the sprint goal is realised and the team gets closer to the product goal. That’s good!
The new Scrum Guide writes about this:
“The sprint goal is the only goal for the sprint. Although the Sprint Goal is a commitment from the developers, it provides flexibility in terms of the exact work required to achieve it. The sprint goal also creates coherence and focus and encourages the Scrum team to work together rather than on separate initiatives.”
Hopefully, this is the first step towards teams no longer working through their tickets in maximum division of labour. Hopefully, it is also a step towards pairing or even mobbing. Never code alone!
The “what” and the end of endless estimating
The second level is the “what”. The organisation of the “what” has been the actual domain of Scrum so far. The “what” serves to clarify the question of what the team should or should not work on next.
But there was a problem until now. Prioritising tasks was a vexed issue, because prioritisation was based on a concept that no one could really grasp: Business Value. Ticket tools such as Jira or Mantis exacerbated the problem because these tools did not forget anything. This is fine for managing issues, which is what these tools were intended for. As a result, backlogs got bigger and bigger. I know of backlogs with several thousand entries.
In any case, prioritisation, estimation, grooming and refining were the order of the day. These constructs are a sign of waste.
The No Estimates movemen t set a counterpoint here and rightly asks in what way this “estimating” contributes to product development at all?
Now there is a clear framework for prioritisation and this is set by the product goal, i.e. the “why”. This makes prioritisation easier. The only question now is:
“Which issue will bring us decisively closer to the product goal in this sprint?”
The answer to this question is the sprint goal, which can now be filled with tasks, stories or whatever.
In the Scrum Guide 2020, the term “estimating” has been removed
Consequently, the word “estimating” has been eliminated from the 2020 version of the Scrum Guide. In place of “estimating” comes the new term “sizing”, which I like much better. The upcoming tasks are cut in such a way that they can be processed as increments in the sprint.
Folks, put away your planning poker cards. They were fun, but let’s face it, if you are doing Planning Poker, it means you don’t have a clear goal and the “sizing” of the tasks is not right.
The “how” and the self-managed team
Now that the nitty gritty of backlog prioritisation is gone, there is also an interesting twist on the topic of self-organisation. Self-organisation becomes self-management or the self-managing team.
What is the difference? The article “The Difference between self management and self organisation ” describes the difference very well:
- Self-organised means that the team decides and is responsible for the “how” of the task completion. This was the task of the old “development team” in Scrum3.
- Self-managed or self-led means that the team is responsible for both the “what” and the “how”. The “what” is now no longer a lonely and often incomprehensible decision of the product owner, but is the responsibility of the entire Scrum team.
The “why” becomes the actual leadership task, which must now be defined in the context of an entire organisation, even outside the Scrum team. This is where, you guessed it, the OKRs come into play.
- Dave West described the new product goal nicely when he published the Scrum Guide. Here is the video excerpt ︎(below the list)
- So it makes me a little sad that only now, after 25 years of Scrum, the importance of a “business case” for product development is being recognised. Prince 2 sends its regards. ︎
- I am of the opinion that the construct with the developer team in the Scrum team has always been a bad idea. This is also correctly gleaned from the new Scrum Guide