Top 5 mistakes defining your OKRs
Avoid these common mistakes when committing to your OKRs.
By Humphrey Fredriksz
One of the key practices in boasting your agile organization is to work with the OKR process. This process aligns the whole company every quarter on what the organization wants to achieve and ensures that all teams work towards these company objectives. One of the biggest complains about traditional agile working is the pitfall of turning agile teams into silos which are piercing the definition of self-organization to self-determination of what is best for the company.
Here you can read about how to turn your OKRs into a roadmap and in Jira. Below you can read about the 5 biggest mistakes when defining your OKRs
1. No good preparation time for estimations
Start your preparation of your OKRs at least 4 weeks before the new quarter starts. Starting later is setting your team up for failure. How can you team commit to big topics which they haven’t explored yet. We have seen teams start talking to each other during the quarter and finding out that they totally misunderstood the request or that the technical solution won’t work. At least have a concept of requirements ready to go over with all teams involved and ask what is needed to do a proper estimation.
“This is still happening most of the time. Teams take their full capacity and plan in all the OKRs / features, just to fool their stakeholders.“
2. Not managing your dependencies with other teams
You can only go so far for some time, but at one point you will be depending on other teams (can also be non-agile teams). Or other teams are depending on you. In order to manage your dependencies correctly, you need commitment and a high-level planning, and you need to have their approval noted in the OKR sheet. “Did you align with dependencies with other teams YES/NO”. If you have any doubt about? Please don’t assume but get confirmed.
3. Reserve time for learnings
Developing software is never perfect, same goes to products. Developing a feature and releasing it to users will tell you if your idea is paying off. Product management practices show that you need 4 to 5 iterations on average to get your feature successfully adopted by your end-users. This sounds a lot, but the message is to at least reserve time in your epics (roadmap) to iteration on learnings and feedback from users. This gives you a no stress pass to turn your product into a lovable product.
4. Epics are too big
When you develop software, one of the keys is to build, release and learn. This means you’ll have to break down your features or work in deliverables which can be build and tested within on sprint. In case of bigger features, get it broken down in max 2 sprints and make sure you can release it to acceptance or production. In order to get feedback from QA or stakeholders. If it’s bigger and you wait too long, you have a high risk of developing something which will not solve the business problem. Seen this happen so often.
5. Reserve full sprint capacity for OKRs
This is still happening most of the time. Teams take their full capacity and plan in all the OKRs / features, just to fool their stakeholders. During the sprint, your team needs time to release, hotfix, analyze and maintain their product. A rule of thumb is to reserve around 30% of your time during the sprint for these activities. Be realistic and be able to explain this to your stakeholders, even if they don’t understand it. Welcome to the world of IT.
Do the agile team assessment
Is your team kicking ass or trying to get there? We build an agile team assessment to understand exactly where they lack and how they can improve. Great insights to improve impact, predictability and team spirit.
Accelerate Agile teams
What we analyse:
MyValueCoach is an online coach for agile teams. We analyse, coach and accelerate teams worldwide.
Change the world of education and help talents all around the globe to work together.