I doubt you’ll find any startup, high growth company or enterprise that is choosing to implement OKRs and doesn’t have a backlog of work already defined, prioritized and in some stage of development. This proves to be an interesting challenge when the decision is made to change the goal setting framework away from output to outcomes. What happens to the work we’re already doing? We worked hard to build consensus, alignment and commitment to specific tasks and features. Do we start from scratch?
We worked hard to prioritize our backlog
Most teams are loath to throw away this hard-earned consensus. Instead, they attempt to adapt the objectives and key results framework to the existing backlog of work already defined. The anti-pattern that develops is one where each backlog item that doesn’t “fit” into one of the team’s new OKRs triggers the development of a new objective, key result or both. The team doesn’t trust that management will evaluate them based on the new outcome-focused goals. To ensure a good performance assessment and visibility of the work they have planned for the next few sprints they build a hybrid system that tries to cover both their desired goals and visibility of work plans. The resulting system fails to solve both scenarios.
Backing into OKRs neutralizes their efficacy
As the team builds goals that justify the work they already have planned, the list of OKRs grows longer and longer. Leadership struggles to determine whether the team is targeting the delivery of the backlog or the key results. The odds of them hitting both are remarkably low. The team and their stakeholders default to the easiest way to measure progress and fall back to managing the output of the team.
The binary nature of feature development makes it simple to see if a team is “doing work.” They either shipped the features they committed to or they didn’t. The efficacy of those features, although it may have been captured in one of the many OKRs the team wrote, is lost to the clarity of the “feature factory” process everyone is used to. And the team’s OKRs? They were a temporary distraction from the “real” work of delivering features and are quickly ignored or discarded outright.
OKRs are the filters that sit on top of the backlog
“So we need to throw out our backlog and start over?”
I hear this question regularly. The short answer is yes. At the very least you should be willing to do that. Realistically, you won’t throw away 100% of your backlog. However, once you’ve set new goals it makes perfect sense to reevaluate whether you’re working on the right things. OKRs function as filters that sit on top of your backlog. For every existing work item the team follows this script:
- Ask: Will this work item help us achieve one of our key results?
- If the answer is no, we remove the item completely from our product backlog.
- If the answer is yes, we add it to our product backlog.
- If the answer is maybe, we add it to our product backlog as a learning (product discovery) activity.
- Ask: Which of the items in our product backlog will help us move the fastest towards our key results? The answer here becomes your next sprint backlog.
Some of your existing items will make it through. Some won’t. The items that don’t go through aren’t necessarily tossed in the bin. Instead, they go into the “not now” list. As our learning evolves, so will our goals. Perhaps in a future iteration of the product these temporarily rejected items will find their way into the product backlog. By using OKRs as backlog filters we establish our key results as our targets while reprioritizing the backlog to reflect these new goals. When our stakeholders ask why our work plan changed we now have an objective, evidence-based answer.