Book: Succeeding with OKRs in Agile (2nd Edition)
Author: Allan Kelly
Part: II — Writing OKRs
Chapter: 13 — OKR cycle
Reading time: 7 minutes
Tags: okr-cycle cycle-length quarterly-planning okr-setting-vs-work-planning sprint-okr-relationship cycle-cadence planning-separation work-planning cycle-timing okr-process-design
Summary: This chapter defines the OKR cycle — typically quarterly but adaptable — and draws a critical distinction between OKR-setting (strategic: what to aim for) and work planning (operational: how to deliver). Kelly argues these should be separate activities, with work planning happening inside the cycle rather than before it. The chapter also discusses cycle length trade-offs and how OKR cycles interact with sprint cadence.
13. OKR cycle
The motto I’m advocating is: Let chaos reign, then rein in chaos. Does that mean that you shouldn’t plan? Not at all. You need to plan the way a fire department plans. It cannot anticipate fires, so it has to shape a flexible organization that is capable of responding to unpredictable events.
Andy Grove, CEO, Intel
The word ‘planning’ gets overused; it pays to look behind the meaning. So when someone, even me, writes ‘Plan OKRs for the next cycle’, they might mean ‘Set OKRs for the cycle’, or they might mean ‘Decide what needs to be done in the next cycle to deliver the OKRs (which have been set’). Both are planning, but they are different.
I’d like to draw a distinction between planning that sets the OKRs and planning work to deliver OKRs. Both are needed, but it serves to see ‘OKR planning’ as a two-step processes: first set the OKRs – focus entirely on the outcome(s) you want to achieve. If it helps, just imagine everything is possible. Having decided on the outcomes you want to bring about, you can now proceed to the second step and decide on the work to be done.
This chapter looks at how to plan the work to be done. Other chapters in this section describe setting OKRs. While OKR-setting and planning cuts across all chapters, Chapters 17, 21 and 25 discuss it specifically.
OKR planning is a two-step process
Setting OKRs requires broad thinking. System thinking and design thinking are useful when deciding what goals to set. Deciding what work is needed is part of the narrow execution process. Systems and design thinking take a back seat – blinkers might be more useful to limit distractions.
13.1 OKR cycle
The OKR cycle begins, like a sprint, with a planning meeting. Only this planning meeting is not to break work down and schedule it, it is to set the objectives and decide on the key results. Indeed this might take more than one meeting, and will typically occur a few days before the start of the OKR cycle.
As with sprints, OKR cycles follow OKR cycles and there probably isn’t a gap between them. This means that after the first cycle there is work to do closing off one cycle – review work, assess progress on OKRs and hold a retrospective – as well as planning the next set of OKRs.
But there is a difference. It can be hard to plan the next sprint until the current one is fully closed off. Although one shouldn’t roll work from one sprint to the next, it happens, and stakeholders can find it hard to decide on priorities until they see what has been done.
I encourage teams to wipe the slate clean and start with a blank piece of paper when planning the next set of OKRs. Just because a previous OKR was only 85% done does not mean that 15% of the work rolls over. The 85% that was done is still valuable and should be delivered. When planning a new set of OKRs, teams should be asking “What is valuable today?”, rather than “Which thing which was valuable ten weeks ago and still needs to be done?”
Consequently it is easier to think about the next OKR cycle during the final days of the current one. The tail of one cycle will overlap with preparations for the next.
13.2 Cycle length
It is traditional to run OKR cycles on a quarterly basis: 12 or 13 weeks. Quarterly thinking is common in larger companies: sales targets, portfolio reviews, personnel reviews and more all happen four times a year. So why not OKR cycles?
To start with, it is exactly because quarterly cycles are already busy that you might consider another time period. If you want full team involvement and senior manager’s time, you will have a lot of competition. Of course one might offset quarters to reduce this: January, April, July and October for sales quarters; February, May, August, November for OKRs. It is still a packed schedule.
There may also be a tendency for these cycles to interfere with each other. Will sales targets or performance reviews distort OKR-setting and delivery? Or simply get in the way?
One option is to use a different cycle length. OKRs could be set on ten-week cycles. This would allow for five cycles per year with a two week break over holiday periods. Or perhaps three 17-week cycles?
When first starting with OKRs it can make sense to do two short cycles to practice the process. For example, two six-week cycles before settling into a regular ten or 12 week cadence. This would accelerate initial learning. Such an approach might also allow a team to synchronize with other teams who are part way through a cycle.
13.3 OKR-setting is not work planning
So far I have been keen to describe objectives as ‘outcomes that you wish to bring about’, or simply ‘desired outcomes’. Outcomes are not in themselves work to be done. There will be work to bring the outcome about, but that is yet to be determined.
For some, key results are the work to be done. When you see KRs as (Type 3) Lego bricks that can be assembled into an objective, then OKR-setting and work planning are pretty much the same thing. Viewing KRs as acceptance criteria gives a different perspective: key results are not tasks and do not form a to-do list.
Objectives and key results describe the target end state rather than the route to that state. It follows therefore that in planning and setting OKRs teams are not assessing the work to be done. The primary task in OKR-setting is to decide the destination. Inevitably some discussion of ‘Is it achievable?’ and ‘How will we get there?’ will occur, but this should not dominate the discussion.
Particularly for teams creating ambitious OKRs, a gut feel of ‘challenging but achievable’ should suffice. If discussion lingers too long on ‘what needs to be done’, teams self-limit and become distracted from desirable outcomes. In other words: teams agree on what they can do rather than what benefits stakeholders.
OKR-setting is not work breakdown. Work breakdown happens after OKRs are set. This follows the ‘right to left’ planning approach advocated Mike Burrows¹ and Bent Flyvbjerg². OKR-setting is ‘outside-in’ rather than ‘inside-out’: work from what is required back to what needs to be done, rather than what is to be done to what might be needed.
Within each OKR cycle teams run their regular agile method as before. Scrum teams run sprints, XP teams run iterations and Kanban teams hold replenishment meetings. The big difference is that OKRs are central to each planning. OKRs are not something teams do in addition to their regular work – OKRs are the regular work.
13.4 What about work planning?
OKR-setting and work planning is a two-step process. The first step, which needs to occur before the cycle start, is to set the OKRs. The second step is to work out what needs to be done. For this there are multiple options.
The simplest option is to wait until the work is about to be done. So the first Scrum/XP planning meeting of the first sprint in the cycle looks at the first priority OKR and works out what needs to be done this sprint. Teams can perform work breakdown, generate stories and tasks or use whatever approach works for them.
The team then repeats this process every planning meeting. This approach would certainly fit with the ‘just enough’ or ‘just-in-time’ planning philosophy, but it is unlikely to satisfy
¹Right to Left: The digital leader’s guide to Lean and Agile, Mike Burrows, 2019
²How big things get done, Bent Flyvbjerg and Dan Gardner, 2023
everyone.
Three options for work planning
The second option is to use the first sprint planning to plan out all the work to be done. The team might confine themselves to one OKR at first and delay working on the second until the first is done. If the team needs to plan out work for multiple OKRs in parallel, they will probably need to address multiple OKRs.
When a team sees the need for a lot of work planning it may be better to hold a dedicated planning meeting rather than squeeze it all into sprint planning. The question which arises now is: should this occur before or after the start of the OKR cycle?
There is a logic to holding the work planning meeting before the OKR cycle starts. However, this steals time from the previous cycle, which might be difficult to spare. There is also a possibility that the OKRs might change before the cycle starts. Indeed, the earlier the work planning happens, the greater the chance that something will change.
The alternative is to put work planning right at the start of the new OKR cycle. Focus is increased because the previous cycle is finished, the time comes from the appropriate cycle and potential disruption is reduced. However, this ‘just-in-time planning’ will make some people nervous.
Personally, I tend towards the little-and-often approach, even if sprint planning meetings need extending. If more upfront planning is required I would avoid doing it in the previous cycle, to maximise focus in both cycles.
Estimation?
Once OKR-setting is separated from work planning it becomes clear that estimating work effort during OKR-setting is misplaced. To estimate the effort required, it is necessary to have some understanding of the work which will be done. So without even a high-level work breakdown, estimation is not possible.
Since OKR cycles are time-boxed, even asking “Wow long will it take?” is the wrong question. Rather, teams should be asking “What is possible within the time box?” and “How much can we do within the remaining time?”.
For bigger work that potentially spans multiple cycles and even years a completely different approach is called for. Inside-out approaches – where the work to be done is determined, each item estimated and a total work effort divided by some denominator (work days, story points, the spin of a roulette wheel) is doomed to failure. Human estimation is problematic enough, but no work breakdown is ever comprehensive and those that try offer too many hostages to fortune.
Monte Carlo simulation offers some promise, but this needs historic data. Bent Flyvbjerg has pioneered an outside-in approach called ‘reference class forecasting’, but this also requires historic data.
13.5 Summary
- OKR cycles can be any length you like and the default 13-week cycle may not be the best.
- OKR-setting is not work planning. Work planning is a separate activity that follows setting.
- Work planning can happen a little and often at the start of each sprint, or it can be front-loaded with dedicated planning sessions. Preferably such planning should happen inside the cycle and not before.