How do your internal stakeholders (e.g., team members, QAs, PO/PMs, Customer Support) report any bug that they may find?
I’ve seen some companies allowing everyone to access Jira and they would directly open a ticket there. In other companies they would thext the PM on Slack, the PM then creates the ticket.
How do you make sure that the reported bugs are detailed?
JIRA Service Desk, create a Form for them to follow with some custom fields with key information to segment them across dev teams if necessary. You can also create Slack integrations to dedicated channels to monitor them as they come in, it works well currently but we are not inundated with tickets at the moment…
The main reason is to have ONE source of truth, in this case, Jira. The moment your tickets are tracked in multiple systems, youre doomed.
Second reason is discipline. No ticket - no work, sorry. My team can’t follow up on everything in chats.
The third reason is the update status. Instead of replying to every stakeholder on the status, I say, “read comments in the ticket. They, and the task status, are the latest updates on your request.”
When there’s overflow of such tickets, I use a Triage board - a dedicated board with filtered tickets submitted by stakeholders.
We also have a separate kanban for enhancement requests.
For both we have PM, QA, engineering represented. In my past a Project manager would attend but we don’t have those at my current company and instead a delivery manager will attend to notify sales.
It’s a kanban board that filters specific types of tickets - usually “application support tickets” that have types of “Task,” " Bug," “Enhancement,” " Ad-hoc," etc.
PM, PO, or EM check that board regularly and prioritize based on SLA. This usually means some items jump into the current sprint, some get parked for the next ones, and some backlogged/rejected.
I used to monitor an inbox early in one project and just use that for JIRA creation. Eventually we transitioned to service now tickets that I’d triage and decide if they needed to be logged as a bug in JIRA, a training opportunity, or an enhancement request. I don’t like the idea of everyone having access to JIRA bc most people don’t know how to use it and aren’t fully aware of what the product does and doesn’t do, if something is already captured, etc.
I feel like it looks obvious to give access to jira to all other stakeholders, but I agree with some of the other comments saying “not everyone knows how to use it”, “not everything that’s reported is a bug”, “they dont always know the correct urgency of the bug”.
In a way not all tickets they create should be in the backlog. You would still need to go through all the tickets one by one, and check what makes sense and what doesnt.
Agree not everyone knows, wants to learn, or should be allowed to use Jira, but then you need “dedicated loggers” of some kind, whether that’s frontline support, QA, PO, PM, or semi- trained minions. Also agreed that the more roles who are entering bugs, the lower the quality of the bug report will be (filled in, described well, or missing repro steps, images, data etc). In general, ppl closer to the action, log better bugs (qas, dev, po/m) because they know they will have to deal with it later.
Yes, you will always have to triage the bugs. Usually there is a separate project for receiving bugs/tickets into (holding tank), they get triaged here then moved to the appropriate backlog (if serious, worth fixing etc). Who does the triage varies widely, QA, Dev, PO, PM, this will depend on who really calls the shots in Eng. Should be PO/Pm, IMO. Bugs that are deemed not worthy they should be closed quickly with a note as to why (not a bug, can’t repro, won’t fix).
Enhancement/feature requests are not bugs and should go into a separate list as well and priorized differently.