You Should Nuke Your Backlog Every Quarter (For Real)

Your organization has passed down a mandate that you’re going to do OKRs (think: Thou shalt use OKRs). Now what? And where does the backlog play into your OKR strategy?

Allan Kelly is an Agile coach, author of seven books, and keynote speaker. His introduction to OKRs was exactly this — it came down as a mandate and he had to figure things out.

Allan has some controversial ideas around maintaining a backlog (like deleting it and starting anew every quarter). 

He also believes it’s okay not to achieve your OKRs. In his mind, delivering benefits for the business is far more important. Read on to learn about these surprising perspectives based on Allan’s insights from his Dreams with Deadlines interview.

10-Second Summary

  • Every OKR is a type of hypothesis. In setting OKRs, you are hypothesizing that this list of things you've written down will benefit your organization and stakeholders.
  • In defining their OKRs, the team defines their own space, because OKRs place boundaries on what the team will and won’t do this quarter. It's a team-driven process, more bottom-up than top-down. That’s empowering.
  • There are legitimate reasons for not hitting OKRs. It makes sense to stop and reflect at the end of an OKR cycle — evaluate how you did it, what happened, how you handled it, and come up with improvements for next time.


What comes first: the OKRs or the backlog?

When setting OKRs, you might have some questions. Do the OKRs come from your backlog, or does the backlog come from your OKRs? Should you craft OKRs that reflect what you intend to do, drawing from the backlog? Or do you set OKRs first, then the backlog has to fall into place? 

The answers start with senior leadership.

According to Allan, the leadership team should be about vision, mission, and purpose. They should paint a picture of where they want to go — Allan suggests they shouldn’t go any further than that. 

He says senior leadership should paint the vision and then leave white space in the plan. And then the teams come back with the OKRs so that they come from the bottom up.

To craft good OKRs teams should: 

  • Look at what their specialists — product managers, product owners, and whoever is thinking about what customers want — have to say; 
  • Listen to senior leaders say about the organization’s goals; 
  • Examine products and services


Toss the backlog — yes, really 

OKRs can become a way of organizing and filtering your backlog. You can wipe the slate clean every three months and decide to forget the past. If you aren’t bound by what you've written in the past — and just focus on the outcomes — Allan finds you will get a better result. 

That’s why Allan goes to the extreme and essentially throws the backlog away. When sitting down to set your OKRs, he suggests you ask yourself the following questions: 

  • What will make a difference to this team and this business? 
  • What will make a difference to these customers?
  • What are the outcomes we want? 

Then, focus on those outcomes. Your success is measured by the benefit you deliver. 

You may be wondering: should you ever derive your OKRs from the backlog? Many teams are measured by the quantity they deliver. In those circumstances, it does make sense to craft your OKRs around the subsection of backlog. If that is what your organization is asking you to do, and if that is what your organization considers success, not doing it would be unwise. 


How to avoid set-and-forget with OKRs

It's quite simple, says Allan: remove the backlog, and every time you need to decide what to do next, go back to your OKRs. Allan says you can even walk into your Scrum meeting with no preparation whatsoever. 

He suggests you can look at your OKRs and ask:  

  • Where are the OKRs? 
  • Which OKRs or KPIs are we going to focus on in this sprint? 
  • What do we need to do to move them forward? 

Then, write out your tickets and start working on them. That's the basic model. The work that goes into your sprint should be coming directly from your OKRs. 

Each time you need to decide what to do next, go back to your OKRs and ask: 

  • Which OKR are we focusing on?
  • What do we need to do to move it forward?


At the end of the day, OKRs are all about benefit 

According to Allan, delivering benefits is the ultimate goal. 

It’s more important than making progress on your OKRs. Note that he uses the word benefit — not value — because “value” often denotes a dollar sign. “Sometimes benefit is more important than money.” 

Allan says that at the end of the quarter, if you can look back and say, “look, we missed every one of our OKRs, but we delivered a lot of benefit; we did things that have improved people's lives,” that’s progress. 


Quick tips for OKRs

🚨 Something’s got to give

If you simply do what you were doing before, and you add Agile and OKRs, then you've got all the overhead, admin, and everything else you had before — plus you've got this new thing and the overhead of making the two of them work together. 

If you’re going to use OKRs,” Allan says, “then stick to that and let go of everything else.” 

When you work with Agile and OKRs, the process can be helpful for reflecting on you the things you need to change. When certain difficulties arise, it might not be a problem with Agile or OKRs. It could indicate a problem with the company that needs addressing. 


🚨 Every OKR is a type of hypothesis

One clever way of setting OKRs is to write them as hypotheses. Instead of making the achievement the objective, you make the test the objective. The fact that you run the test means that you can consider it achieved. 

Allan thinks of every OKR as a type of hypothesis. In setting OKRs, you are hypothesizing that this list of things you've written down will benefit your organization and stakeholders. 

If partway through that period, you realize that your OKRs will not add benefit, there's no point in continuing. You also might learn something that illuminates something more valuable, which leads to a pivot. 


🚨 Don’t chase ‘shiny’ things

One of the problems with OKRs: they can get to feel a bit stale. People are attracted to new and different. But you need to pay attention to the “shiny” things you built six months ago. 

If you’re partway through the OKR cycle and you realize you've got a problem, it would be negligent to continue to pursue your OKRs. However, it's also irresponsible to move away from your OKRs every time something unexpected happens. Sticking with something old while knowing when it’s time to move on is a balance that is hard to achieve. 

When it comes to judging the success of your OKR cycle, consider stepping away from simply crossing off your OKRs. The ultimate sign of success or failure isn't how many OKRs you hit — it's the benefit you achieved.



This article is based on an episode of Dreams With Deadlines by Gtmhub — the strategy-meets-execution podcast where you'll hear of real trials and victories in business. The show is hosted by Jenny Herald, VP of Product Evangelism at Gtmhub. Subscribe via Apple, Spotify, or wherever you listen to podcasts to hear their discussions with thought leaders and learn how to shrink the gap between strategy and its day-to-day implementation. 


✍️ Top quotes

“You're publishing your API in a standardized format, called Objectives and Key Results. And you can read other teams, standardized formats, and you can compare and you can give feedback, right? And in defining this, the team is defining their own space because those OKRs place boundaries on what the team is going to do and what the team is not going to do this quarter.”

“Your OKRs, at best, become a way of organizing and filtering your backlog. But actually if every three months you wipe the slate clean and say, forget the past, the past is gone. … let’s not be bound by what we've written in the past. And we focus on just the outcomes, I actually find you get a better result.”