In the past days we have talked about Atlassian products and applications, their usefulness and the ways in which you could make them a part of your team’s work. We hope that you found our tutorials helpful!
This, however, is not the end of our Atlassian journey. There are many more topics to discuss. After giving you an overview of all the possibilities that Atlassian has to offer, we think it is high time we show you a real-life example.
In this article we will explore how OpenMRS, one of the biggest open-sources out there, is making use of one of Atlassian products – Jira Software.
OpenMRS
For those of you, who might be unfamiliar with OpenMRS, here is a short description:
The OpenMRS community brings together a diverse group of individuals with expertise in healthcare, global health, software development, quality assurance, and implementation. These contributors bring a wide range of skill sets together and work collaboratively to build and maintain a robust, electronic medical record system platform.
OpenMRS has been our partner for a long time. We have collaborated on many projects. We can also proudly say that the current OpenMRS’ website was created by SolDevelo Foundation.
If you want to know more about the website designing process, check out this article: OpenMRS New Website Finally Launched!. We also encourage you to go through categories dedicated to OpenMRS on our blog to find more interesting information on our collaborations.
OpenMRS & Atlassian
Every organization needs proper tools to manage its work. As many other open-sources, OpenMRS is using the products of Atlassian. Why? It is an intuitive choice for many organizations of this type. Not only is Atlassian’s offer flexible and diverse, serving many different purposes, but it is also mostly free of charge for nonprofits and open-sources.
Considering all of that, it is not big of a surprise that OpenMRS became one of Atlassian’s users. In this article we will focus on their use of Jira.
What features of this software did they find helpful? Read on to find out!
OpenMRS & Jira
We have already published a wide range of articles covering the different aspects of Jira and Jira Plugins. Therefore, we highly recommend you to read them and find out what Jira is and how it can help your team. If you are interested, search in this category.
Managing an open-source project with many different users coming from different parts of the world, it would be nearly impossible to operate without a flexible tool that can handle numerous tasks, their progress and current status. Jira takes care of all of that and even more. Moreover, with the help of the worklogs plugin, which OpenMRS is also using, Jira allows to track the number of hours spent on every task by every user.
Using Jira lets the OpenMRS community arrange their work, distribute tasks, and discuss current problems, while having a clear view of the backlog.
Another important feature is prioritizing tasks. In such a big community it is crucial to organize issues by how urgent they are. Otherwise, the most important things to do would get lost among many other minor tasks. Jira allows you to set the priority, so that everyone can see on which issues the most focus should be put.
Something that can’t be omitted are also workflows. A Jira workflow is a set of statuses and transitions that an issue moves through during its lifecycle and typically represents processes within an organization. What it means is that the successive stages of your task will be different depending on what workflow you choose to work in. Again, Atlassian offers a lot of flexibility in this aspect. You can change workflows, to find the one that suits you best. You can also create new ones or search through the Atlassian Marketplace for the ready templates. It is important to choose your workflow wisely, in order to avoid confusion caused by too complicated structure.
A Little Bit of Mess
From what we are writing it may seem that Jira is a great tool that can help you in many different situations. And while this statement is certainly true, we have to bear in mind the fact that no matter how great a tool is, it is a man who uses it. Depending on how the tool is managed, the outcome can be completely different.
When it comes to Jira there is a high risk of neglecting regular clean-ups of the backlog. It is especially problematic when there are many users taking part in many projects. New tasks appear all the time. However, not every single one of them eventually meets its happy ending with the Done status. Some of them end up stuck in the backlog forever, lost to the human eye among many other similarly less important tasks.
Reasons for this vary. Sometimes the task just wasn’t crucial enough for anyone to undertake it, because there were so many more urgent things to do. The other times the task didn’t make it through the reviewing process and something needed to be fixed, but never was. A lot of issues become outdated and useless after some period of time, because the situation always changes. One of the inevitable things in IT-based projects is technical debt. Technology is evolving and developing very rapidly. Therefore, some of our tasks and projects may become outdated for the reasons that we can’t control. Every company struggles with technical debt. It is very difficult to manage tasks in such a way that the debt is minimized.
Due to these and many other reasons the backlog can get a little bit messy with time. In a small team it can be inconvenient and make operating in Jira more annoying. However, when it comes to a community as big as the OpenMRS one, such neglect can lead to serious problems with navigation through the backlog, clogged with an enormous number of forgotten or outdated tasks.
Unfortunately, this is exactly what happened to OpenMRS.
In October 2020 about 41% of tasks existing in their Jira backlog were last updated more than 4 years prior to the date. Average age of open issues was between 4 and 5 years old.
Manual searching through around 5,000 tasks must have been a nightmare. The number of tickets made it impossible to figure out what is important right now, and what should have been closed a long time ago. Consequently, the backlog became useless.
That is why the OpenMRS community came up with a plan of solving the problem.
Graveyard Project: Cleaning up the Backlog
At first, the community discussed the problem on OpenMRS Talk, proposing the ideas on what strategy will help them deal with cleaning up the backlog. One of the considered solutions was to switch the platform. Replacing Jira with GitHub would mean leaving some of the mess behind and starting anew. After some discussion, however, this idea was rejected. Jira is what OpenMRS users know and are used to. The conclusion was that the problem lies in flawed processes, not in the tool itself.
To fix that, a new strategy was needed. One that would not only help in cleaning up the backlog, but also simplify the usage of it. That is how the Graveyard project came to life.
The main goal was to close all of the tickets that were not updated for longer than a year, unless their creators or executors explain why the certain ticket still needs to be active.
The action was announced to the community two weeks before the planned cleaning, along with an explanation on why it is needed and an instruction on what steps should the community members take. Additionally, a list of all outdated issues that were to be closed was provided. The community had two weeks to examine them and decide whether there are any specific reasons to keep them open.
Eventually, in the first part of the Graveyard project more than 3,300 tasks were successfully closed.
Towards Clearer Future
After this big triumph over the chaos, it was decided that the backlog cleaning of this type will be conducted regularly every quarter. Further steps to improve the usage of Jira were also taken. One of them was simplifying the workflow used by the community, so that it is less confusing and easier to navigate through. Another initiative are monthly Jira Ninjas sessions, open to every member of the community and focused on reviewing more recent tickets in order to keep the backlog up-to-date.
All of the effort put into the Graveyard project is truly admirable. The success of this action serves as a proof that nothing really is impossible, if only we are working together. This situation is, at the same time, a lesson for all users of Jira: you might be good at using it, but you have to be good at cleaning it, too. Otherwise, it will eventually become useless.
Lessons Learned
We hope that you have found this story useful. It is a lesson also for us in SolDevelo Foundation. While cleaning up is certainly not the most pleasant thing to do, it is important to get yourself together once in a while, and take care of your Jira backlog. After all, it is the tool that is meant to make our work easier, and not even more difficult.
Managing a project requires being conscientious and attentive to details. It is necessary to regularly inspect not only the content of your work, but also the mechanics of it. You have to take care of your working space and your tools.
This rule applies to any type of project that you are working on. If you want to cook a dish, you must first make sure that your kitchen is clean, your knives are sharpened and your oven is functioning properly. And it is not enough to do it just once. You have to keep your kitchen well-organized and well-maintained to be able to use it every single day.
The same goes for digital projects and tools. Jira is our kitchen that we have to regularly maintain, in order to keep it useful and helpful. However, it is important to notice that nothing happens by itself. If the task of cleaning the backlog is not scheduled and not assigned to anyone, it is as if it did not exist at all. There has to be someone responsible for taking care of outdated tickets and the overall maintenance of the backlog. And if everyone is responsible, then in reality no one actually is. According to Scrum, this task should be assigned to the Product Owner, who is accountable for maximizing the value of the product resulting from the work of the Scrum Team.
Another good practice is to dedicate a part of every Sprint to work on the tickets that are old, but there are reasons for not deleting them just yet. This way, you can progress with your backlog cleaning process and steadily resolve issues that clutter up your backlog, while at the same time going on with your current projects.
This case study inspired us to take a deep look at our own backlog and freshen it up. We hope that it will inspire you, too! If you are still willing to learn more about Jira and other Atlassian products, check out our tutorials.
We will end this article with wise words of Grace Potma, the OpenMRS Director of Product and main coordinator of the Graveyard project:
“We can’t show our community that Jira is a serious, meaningful place, until we are humanly able to use it meaningfully.”
