We started using OKRs this past year. I can't tell you what our current OKRs are. We even create "sub-OKRs" that align with the higher level OKRs. It feels like a pointless exercise, because we do what the author describes: slap labels on items in our backlog that sorta-kinda relate to an OKR.
The author's suggestions aren't terribly complete or practical. I don't know many teams who could just dump their backlog every quarter. You're going to have work that can't be related to OKRs. We do use the OKRs to drive our weekly meetings and sprint planning.
One suggestion I have is just to accept all work isn't OKR related and reserve capacity for that work. If some PM or manager complains, push back.
This is exactly what we do. We reserve about 25% of every team's capacity for "other" stuff, e.g. maintenance. The PMs/leaders have to acknowledge for that when they compile their OKRs.
This just means someone somewhere has an unstated objective that things be maintained. Make them write it down, and then your 25% capacity supports that.
The author's suggestions aren't terribly complete or practical. I don't know many teams who could just dump their backlog every quarter. You're going to have work that can't be related to OKRs. We do use the OKRs to drive our weekly meetings and sprint planning.
One suggestion I have is just to accept all work isn't OKR related and reserve capacity for that work. If some PM or manager complains, push back.