Scrum Agile Project Management

Succeeding with OKRs in Agile

“OKRs” is the acronym of “Objectives and Key Results.” This is a collaborative goal-setting tool used by teams and individuals to set goals with measurable results. In his book “Succeeding with OKRs in Agile”, Allan Kelly explains why he considers that “OKRs have the potential to reawaken the early ambition and drive inherent in agile. This time managers can join in too, not as obstacles to change, or change drivers, but as partners focused on the same outcomes for a greater purpose.”

Succeeding with OKRs in Agile is a book that goes into great details about the relationship between OKRs and Agile and you will lose a lot if you stopped at the initial section that presents the most important lessons. The best section for me is the one that explains why to use OKRs and what makes them a good fit for Agile. The full book is always adding an Agile perspective to the OKRs process, for instance explaining how to do sprint planning with OKRs. You will learn how to use OKRs and what are the risks associated to them, providing a balanced view on the possible positive and negative aspects of this approach. The book is easy to read and a summary at the end of each part allows you to clearly see the main points to consider on this topic.

I will recommend this book to every manager that plans to implement an OKRs approach, but also to every manager and product owner of Agile software development teams that might want to add an additional tool to deliver value to the customers and motivate their teams.

Reference: Succeeding with OKRs in Agile – How to Create & Deliver Objectives Key Results for Teams, Allan Kelly,

Succeeding with OKRs in Agile


OKRs provide a link to “the bigger picture” – the purpose, the mission, they step up from sprint-sprint-sprint. Yes, managers have influence in deciding what shall be worked on but managers are entitled too, they are stakeholders too. Managers play a role in delivering OKRs but managers are skilled in managing. None of that means managers can, or should, be using OKRs to boss the team about. Rather OKRs are a mechanism for teams and managers to co-create shared goals which deliver beneficial outcomes.

Good OKRs are outcome-focused. OKRs are not about measuring progress towards a goal. Nor are they about ticking-off work items on a manifest. OKRs are about delivering outcomes that add value. That is one reason they are a good fit with agile.

Despite the hard thinking that goes into OKR setting, the real success of OKRs is not whether any particular objective or key result has been achieved. OKRs are transient objects which serve to focus thinking and work. The real benefit is the outcomes delivered. The ultimate objective of any OKR is to produce an outcome which creates value and benefit to customers, users, and other stakeholders.

Writing and setting OKRs is a whole team exercise where the Product Owner will take a lead. The PO knows better than anyone else what customers and other stakeholders want and need. The Product Owner brings customer requests and product strategy to the discussion – that is their job. Other teams will make requests directly to the team or via the PO. Teams need to agree together which of these are priorities and how they can address them.

Teams live or die by their ability to achieve OKRs. Team members shouldn’t be scared of pulling discussion back to OKRs and asking “Will this contribute to the achieving the OKR?” If you find that the answer to this question is frequently a “No” followed by a direct order to do the work anyway then seek to cover these eventualities in OKRs. If you still find those in authority unwilling to stick to OKRs they have agreed then quite possibly you have a bigger problem.

OKRs need to be central to each sprint planning meeting. Planning meeting need to include a full review of the current OKRs. Go down the list of OKRs: tick those that are done. The Product Owner should then be able to direct the team to the highest priority. It might make sense to look at the objective as a whole or to look at key results one-by-one. Either way the Product Owner should give the team a clear statement of what is the highest priority.

It would be naive to claim that adding OKRs to any team will miraculous turn them into a high-performing aspirational team. Naturally I would love it if this were true but “just add OKRs” is not as simple as “just add water.” OKRs are certainly one tool for nudging a team towards higher performance and greater aspiration but they are not enough alone. Prompting high performance and aspiration requires a supportive environment and culture, in other words psychological safety.