The Objectives and Key Results framework is a goal-setting methodology that helps teams define a clear set of measurable goals for the quarter. It focuses on outcomes rather than outputs, and it's a great way for software development teams to simplify communications with stakeholders. Instead of discussing how a certain project needs to be delivered, the team and the leadership can focus on why such project is required, and what impact is expected.
When done right, OKRs empower teams to own their roadmap with a clear set of objectives to achieve.
There are also many similarities between best practices in software development and best practices with OKRs. You want to have fast feedback loops and work in small increments to make sure that your efforts are producing the right results.
We'll see in this guide some tips to help you write good OKRs, as well as some specific examples for developers.
How to write Software Development OKRs
Step 1. Knowing the difference between OKRs vs. Projects
The biggest change for developers adopting OKRs is to switch their commitment away from the backlog to focus on the goals defined at the start of the quarter.
To do that, it is essential to understand the difference between Objectives, Key Results, and projects:
- Objectives: what do we want to achieve next quarter?
- Key Results: how are we going to measure progress?
- Projects/Initiatives: what are our best bets to get there?
A common mistake is to start listing all your existing initiatives as Key Results. It's quite tempting as these projects are important, but your OKRs should not be a different representation of your roadmap.
A good Objective should be inspiring and easy to understand by anyone in your org. You can be more specific in the Key Results, but the Objectives should give a clear idea of the expected impact at the end of the quarter.
A good Key Result should help you measure progress toward your Objective. A good test is to ask, "would we do things differently if this KR goes off-track?". If the answer is negative, then you need to refine your OKR.
Finally, your projects or initiatives are bets that you make to achieve your OKRs. Some will work—double down on it. Some will fail, and it should be okay to stop and move on to the next idea.
Step 2. Pick 2-3 focus areas
The next step is to pick the correct focus for the quarter. Here are some examples that apply to Software Development:
- Reliability: ensure that the service always works as expected.
- Usability: improve existing features to make the platform intuitive.
- Functionality: deliver new capabilities.
- Security: improve existing protection, and add new safeguards to protect customers.
- Performance: make sure that your application is responsive and scalable.
- Dev speed: invest in your development cycle for faster releases.
Once you have your theme in place, you can go further and turn them into inspiring statements for the team. They'll become the starting point of your OKRs.
Step 3. Write your plan
Once you've narrowed your focus, you can start writing your OKRs. You'll see some examples below, and here's a complete guide on OKRs if you're just getting started.
Example of OKRs for Software Developers
OKRs to reduce technical debt
Reduce significantly our legacy technical debt
Reduce number of issues tagged as debt from 120 to 75
20% of the sprint effort is dedicated to technical debt
Application performance improves by 80% as a result of our work on technical debt
OKRs to accelerate release cycles
Get faster releases through automation
Increase the number of production deployments from 1/week to 4/week
Reduce the mean lead time for changes from 8 days to 72h
Reduce build time from 20mins to 5mins
100% of our services have a Continuous Delivery pipeline
OKRs to launch a successful mobile application
Launch a successful mobile app MVP
Get 100 daily active users on mobile by the end of the quarter
Mobile application NPS is above 30
25% of new active users install the mobile app
Achieve 60% week-4 retention in our mobile application for active users
OKRs for better software performance and reliability
Build a world-class infrastructure
Increase Apdex from 0.7 to 0.98
Reduce the number of paging escalations by 40%
Improve Crash Free sessions from 75% to 95%
Reduce core pages load time to be under 2s
OKRs to increase code quality
Improve our code quality standards
100% of pull requests are reviewed by 2 developers
75% of the developers have gone through QA training
100% of repositories are using code linting and static code analysis
Reduce the percentage of QA-related broken builds by 60%
OKRs to attain great security standards
Attain great security standards
100% of our services have a threat mitigation system in place
100% of devices are enrolled in a Mobile Device Management
All developers score 90+ in our security awareness training
Our policies cover 100% of the ISO 27001 requirements
OKRs to migrate to a new technology
Our JS codebase has migrated to TypeScript
75% of our JS repositories are now using TypeScript
Reduce the use of "any" type by 30%
80% of frontend developers have gone through TypeScript training
Tracking your OKRs
Knowing how to write good OKRs is critical, but without good tracking in place, the OKRs will fade away and focus will be lost.
The easier it is for a team to have weekly discussions around the OKRs, the better they'll execute. Here are a few best practices for tracking OKRs.
1. Do weekly check-ins
Quarterly OKRs should be tracked every week to be effective. Without a continuous reflection on progress, your OKRs won't be much different from having KPIs.
The check-ins process can be automated with a platform like Tability that takes care of reminders, and distribute updates to the teams.
2. Keep track of your confidence
Good progress updates should help everyone understand how far we are from our goal, but also how confident we are in achieving it. You can use a simple red/yellow/green color coding to indicate your confidence.
3. Make trends easy to see
Lastly, it's important to look at trends to avoid false positives. It's not rare for a team to have a hot start and then slow down mid quarter. This will be hard to see unless you can look at progress trends for individual Key Results.
What other metrics can Developers you use?
Now that you've got good Objectives, it's time to pick some key results and finding good metrics that work for your team can be tricky. Lucky for you, we've laid out all the best success metrics for your teams to use.
Here are a few to get you started:
How often an organization successfully releases to production
Mean lead time for changes
How long it takes a commit to get into production.
Mean time to recover
How long it takes an organization to recover from a failure in production.
Change failure rate
The percentage of deployments causing a failure in production
How much of the day/week/month an app stays up & running without interruption.
Number of issues opened divided by the number of issues closed.
Number of incidents
How many incidents happened in production, ideally categorized by severity.
What's the percentage of the code that is tested by automated tests.
How long it takes to complete a build on average. Indicates how long it takes for a developer to know if their changes broke the application.
Review to merge time (RTMT)
How long it takes for a code review to be completed and merged.
Table of contents
Stop wasting your OKRs. Focus on the right work and accomplish your goals.