Setup Menus in Admin Panel


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.


Read more: Why Agile Fails

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

"Analyse and improve your team based on the Value Rocket Framework"

What we analyse:

Why is your team here?

My Value Coach helps you to understand how the team should add business value and achieve their team objectives.

What is your product plan?

Is the team committed to the product vision and the roadmap? Learn how to guide them to build the right features and exceed expectations

How agile is your team?

How is the team developing and releasing the product. Understand how the right skills, roles and structure boasts their deliveries.

Stay connected

About us

MyValueCoach is an online coach for agile teams. We analyse, coach and accelerate teams worldwide.

Our mission

Change the world of education and help talents all around the globe to work together.

Our offer

Copyrights @ 2019 - Website by Runite IT