There are 2 things about our priorities in Jira that are creating problems, IMHO. We’ve been discussing this in the PM Team and I promised to raise these issues here on Talk.
Problem 1: The “TBD” backlog is huge, and could be hiding important things.
42% of all OMRS issues are in “TBD” Priority status.
i.e. almost half of our backlog could contain Blockers or other serious issues, but it’s so hard to tell.
I suspect most people are creating a ticket, and then going and doing something else - and not noticing that it’s been auto-filed as TBD.
Solution: Include the Priority field when the user creates a ticket
I propose that “Priority” should be one of the top fields a creator sees every time they create a ticket in any OMRS project.
The default can still be TBD, but at least this way, if the creator already knows the ticket is really important, then they can identify this right away - and we’ll hopefully be less likely to miss really important issues.
This would also save some PM-Team-time, as we sometimes have to try and figure out the priority of issues that could have already been prioritized by the creators.
Yes, let’s add the Priority field to the Create Ticket screen
No, let’s keep the Priority field hidden in the Create Ticket screen
I have another idea I’ll add in the comments
0voters
Problem #2: The Priority Options are Unclear & Not Defined
Priority Options should help us tease apart the most important tasks, especially since without a big core team we need to optimize our resources as much as possible.
Our current options have 2 categories that are just for low-priority things.
“Should” is overused, and that makes sense: It feels like we “Should” get around to doing as much as we can! But that’s not necessarily a realistic way of prioritizing things.
Our priority labels should intuitively help people break down the Should category even more.
Our Current Priority Options:
Blocker
Must
Should - you could easily argue that most things belong here - which means it’s not a very helpful triage label
Could - it’s hard to label something “Could” when it feels more like a “Should”
Lots of our stuff is in TBD, and lots of stuff is just sitting around in “Should”.
I have been through this problem before. Here’s a short GIF that summarizes what we did, and the impact:
Solution: Update the Priority Labels
We can help people break down the huge “Should” category for us by giving them “High” and “Medium” options. This could help us further triage things that are currently all getting lumped together in the big “Should” backlog.
Proposed Priority Options:
Blocker → Blocker
Must → Critical - clearly, these things should get looked at ASAP
Should → High - these things should be prioritized near the top of backlogs
Could → Medium - I’d like this to get done but it’s not super high priority, but it’s not just a Could or a Low priority, it really should get done
Non-Essential → Low
TBD: Stays around for people who aren’t sure what to do
Yes, let’s use new clearer Priority types, and document clear definitions as well
Let’s just use our existing Priority types, and document clearer definitions
There’s nothing wrong with our existing Priority types, they’re very clear
It depends who is creating the ticket. When tickets are being created by the same people who are curating them, there’s one priority. But (at least historically), tickets have often been filed by implementers reporting issues.
I think the reason priority has been downplayed during ticket creation is to avoid conflating priority of the ticket creator (implementer’s priority) with the priority of the ticket curator (project’s priority), which are frequently not the same.
Sorry for this collection of largely random remarks. I think it would be worthwhile for us (as a community) to be clear about what the priority is for, what it is communicating, and who it should be communicating that to.
That we don’t use priorities consistently, I think, is clear from this chart:
Focusing in, for a moment, on just the TBD tickets, while I’m not too worried about the 203 tickets that are in “Needs assessment” with a TBD priority nor the 12 “In design”, that does leave us 227 unresolved tickets that are somewhere in process of being done with no clear priority (i.e., 22% of the backlog). (On a side note, we should probably be aiming to reduce the number of tickets in the “Needs Assessment” state as—with some additional filtering to exclude Epics—we have 235 tickets marked as “Needs Assessment”)
It would certainly be helpful to have clear definitions of ticket priorities (whatever the labels are called) to ensure that prioritisation provides some sort of useful information—or else I’d wonder if we need it at all. Personally, I’ve found that 5 priorities is more than I can usefully use. For the FHIR2 module this is how I use the priority labels:
Blocker — An active error in the existing code that makes it impossible to release a version of the module.
Must — Ideally completed before the next release
Should — Admittedly, this is the most common status, but generally it means functionality we should have at some point, but which is not critical
Could — Nice to have, but not really necessary
Granted, this schema exists solely in my head and I’m not sure it’s providing anyone with any useful information. I’ve never found a use for “non-essential” (the couple of times I’ve been tempted to create a “non-essential” ticket, I just opted to not create the ticket).
I think @burke brings up a good point, which is that the ticket “priority” might mean different things for different people. We certainly don’t want a bunch of issues showing up as “Blockers” merely because they represent the kind of issue that could be solved on Talk, Slack or IRC (i.e., it’s blocking someone, but not necessarily the project as a whole). And, of course, everyone’s issues are “High priority” for them. On the other hand, if something is a major priority for one of our implementations, that’s something it would be nice if we had a way to capture.
I’d suggest preserving issue priority for project priority (meaning it would only be shown during ticket creation if it can be limited to people who are on the project team).
Implementer priority isn’t always a single thing either (an issue could be a top priority for one implementation and not an issue for hundreds of others), so a single field doesn’t necessarily work for implementation priority.
In the past, we’ve had some success with labels – i.e., have Implementations label tickets that are their top priorities. We’ve also used a “community-priority” label to highlight those issues that are top priority for the OpenMRS community in general.
The “Priority” field is now editable when you first create a ticket:
As you can see, even though the field is required the default is still “TBD”, so I’m not sure how much of an impact this will have on improving our TBD cue.
I’ll leave the priority levels/names as-is for now, but I’m still seeing a disproportionate amount of stuff going into “Should”. Including things I’m triaging myself. Might come back to this in the future.
We’ll continue to use the “community-priority” label as well.
