Jira Improvement Plan, Part 1 COMPLETE: We closed >3,300 issues today

Dear Community,

After positive feedback and help from many with our plan to improve Jira, we completed Part 1: The Graveyard today. In our monthly Jira Ninja’s session we closed >3,300 tickets that had either not been updated in >1 year, or just hadn’t been properly updated when the work was done or cancelled. For hours we reviewed tasks that had been worked on, but hadn’t yet had their PR reviewed. We’re still reviewing some of those tickets so as not to miss out on work already done and just not merged. Huge kudos to @dkayiwa and @ibacher for their work on this :trophy:

Fun Facts

The average age of closed tickets was: 6.5 years old

The average age of tickets remaining: 1.9 years old <-- We’ve obviously got more work to do, but at least we’re closer to seeing more recent issues.

To see the Graveyard

To see tickets closed as part of a “Graveyard” process: (i.e. tickets retired because they didn’t get meaningful follow up within the last year), you can view The Graveyard Dashboard any time: https://issues.openmrs.org/secure/Dashboard.jspa?selectPageId=15751 The tickets are not deleted; they can always be brought back to life if needed. Any ticket closed in a Graveyard process receives the “Graveyard” label; and, the ones cleaned up in this bulk exercise today also received the label “Graveyard 2020-11”.

What if something important was closed?

If you are aware of a compelling reason an old issue should be reopened, please simply re-open the ticket, and add a comment clearly explaining why this ticket should be a priority, along with the impact to your implementation or organization. This really helps us prioritize important work. Make sure you also remove the Graveyard label or we will automatically re-close the ticket in the future.

Here’s what’s coming next:

  • Part 1: Close old things [DONE]
  • Part 2: Archive old projects and close their tickets. We have >160 projects in Jira. I’ve received lots of advice around which projects can be closed, and will now act on this.
  • Part 3: We’ll kick off a more sustainable process - and a Jira Ninjas Club! This is for anyone who wants to learn how to better curate tickets, write requirements, and manage sprints, and will help with sharing the work around the community. This is key to having a more sustainable ticket process so that we never have to go through this degree of backlog management again. More info to come…
  • Part 4: Close other old issues that are no longer helping us manage community work - and get down to <150 tickets per active project. It’s an arbitrary goal to get us down to a manageable number of tickets so we can give the oversight needed - and then we’ll course-correct as needed. I’m going to be asking people for help closing old caches of tickets. Keep your ears opened :slight_smile:

How are we doing?

If you’d like to watch our progress at improving our Jira management, check out our Jira Health Dashboard: https://issues.openmrs.org/secure/Dashboard.jspa?selectPageId=15750

This will show any OMRS community member where our issues are backing up, and where the blockers/musts are, and what things are in need of review/prioritization.

Thanks all!

@dev1 @dev2 @dev3 @dev4 @dev5


p.s. - To be clear, this is not about closing tickets for fun. Our current RefApp release work is a great example of why it’s so important to have a more useable Jira backlog.

Look at our current RefApp backlog: https://issues.openmrs.org/issues/?jql=resolution%20%3D%20Unresolved%20AND%20project%20%3D%20RA

The problem is, this only shows RefApp tickets; not issues related to the RefApp but stored under other projects. The RefApp backlog looks a lot more useable now that we’ve cleaned up old issues. But the backlog is still not entirely helping us identify what we’ll prioritize for the 2.12 release next time. Going through our tickets, especially ones recently identified as blockers or problematic for implementers, will help us serve our implementers better! :smiley:

Now, try looking at our new board for managing RefApp release requirements and bugs. We were able to review a smaller list of tickets based on what had been identified as a priority for a 2.11 release, and we are using the Board view to help us break the work down into sprints: https://issues.openmrs.org/secure/RapidBoard.jspa?rapidView=236&useStoredSettings=true

Well done @grace for this jira Improvements and thanks to @dkayiwa and @ibacher for help :ok_hand:

thanks @dkayiwa @ibacher @grace for making this possible :+1:

Great work :clap: :clap: :clap:

Well done @grace @dkayiwa @ibacher :clap: :clap: :clap: