How we use JIRA and OKR together
A common question is how to tie OKR process with Scrum.
In this post, I am going to explain our approach to OKR and agile Scrum.
Why use Scrum and OKR?
First, people often ask us why do we use both Scrum and OKR – aren’t those just the different ways to do the same thing? We think objectives and tasks are two very different things. To illustrate this, I am going to give an example with an actual OKR we have this quarter.
As you can see from the screenshot above, Damyan is supporting our company objective to make our customers successful, through his OKR to become data-driven about customer success. There are two key results which measure the success of this objective and one key result which puts a constraint in terms of investment.
The important thing to notice is that we don’t say anything about how will this objective be achieved. We could use purpose-built customer success software, we could outsource this to someone, we could build it, we could use Google Sheets… the point is that we as a team don’t really care about how will we become data-driven about customer success, but only that we indeed become data-driven.
So, why do we use JIRA?
Once we have established what we as a company need, it is time to plan the actual effort to achieve this objective. In the case of this particular OKR, Damyan has decided that one of the health metrics (remember, there are 20 that we want to keep track of), should be active OKRs per paying user. Moreover, he has decided to track this metric using Gtmhub SQL insights.
With this, we have an actual effort defined that will help us achieve our objective.
We think of OKR components in terms of questions they answer:
- Objective – What is it that we want to accomplish?
- Key results – How are we going to define success?
- Effort – What are we going to do about it?
So, we use Gtmhub to manage Objectives and Key Results and JIRA to manage the effort.
How we make it work together seamlessly?
You may think, that our approach is reasonable – but that in practice it may make too much overhead. Typically, it would. But this is why we have built Gtmhub.
We hate bureaucracy just as much as the next guy. That’s why our solution allows engineers to work with OKRs from JIRA and everyone else to see how well the effort is going from Gtmhub. And also, our engineers don’t have to update their OKRs – this is done automatically by pulling data from JIRA.
Attaching JIRA issues to OKRs
The first thing we want to make sure is that our engineers don’t have to switch context. So, for example, when Damyan is planning his sprint in JIRA he uses Gtmhub OKRs JIRA plug-in to easily link the issue with his OKR.
Once the issue is linked with the OKR, Damyan will also be able to see the progress on the OKR right within JIRA, without needing to switch to Gtmhub.
Tracking effort progress from Gtmhub
Just as engineers work in JIRA, the rest of the team typically stays away from it. That does not mean that we don’t care how well is the effort progressing on any given OKR. When one uses the Gtmhub OKRs JIRA plugin, all the issues that are attached to an OKR will also appear in Gtmhub next to respective OKR under the section effort. So, for example, we can easily see that Damyan has created 23 issues in JIRA for this particular OKR and that he has already completed 11 of them. In addition to this, we can see the list of all issues and their current status.
We think that transparency, especially between different functions within our company is super important. But, we also don’t want to add overhead in form of parallel reporting. So, this is how we solve this issue.
Updating the key results
In the OKR I’ve used as an example, you have seen that one of the key results is to track 20 customer success metrics.
By now, I think it’s pretty clear, we don’t like to do repetitive, mundane tasks. So, here is how we use Gtmhub to automate this OKR.
Gtmhub can connect to over 100 business systems – and JIRA is one of them. We can extract any type of metrics from these systems and then attach those metrics to our OKRs.
So, what we do here is simply filter the issues coming from JIRA that have label “cs-metric” (you will remember seeing this in the JIRA issue) and use this to count how many CS metrics are we tracking. Every time someone moves such story to Done in JIRA, our Key Result will be updated.
At Gtmhub, everything is a function of our OKRs. The roadmap, sprints, tasks… all of those depend on what objectives we have set ahead of ourselves.
As we are a software company, we use agile scrum methodology – but the stories and epics we log in those, always need to have a backing objective. This is how we fight the “feature factory” and “did it because I could” effects.
Finally, while we are aiming at ultimate transparency, we use Gtmhub to automate most of this process and use our time to do actual work. If you’d like to learn more about how we do this, go ahead and schedule a demo. We’d love to show it to you!