I've noticed that a lot of discussion between a developer and a Product Owner happens in private conversations in various communication tools (Skype, Slack, email, etc). The reason is because these tools are more convenient for communication than Jira.
Are there any good practices to avoid this?
From Agile manifesto:
Your objective is NOT to avoid communication. You want to promote it. People in a project must communicate in the most effective way they see fit. I believe you should shift the focus of your energy, changing the question you're looking for answers to questions such as
These questions might help you fine tune the specific needs for your context. There's no canonical answer as it heavily depends on your environment.
Environment #1: Junior team, low confidence between parts, time zone differences. You still want to keep conversations flowing, but you want to have it written somewhere for future reference. Each conversation might be related to a specific ticket, so the outcomes of this conversation could be summarised as a jira comment. Special attention to outcomes and summarised. You definitely do not want transcripts of conversations (as I saw someone doing some years ago).
Environment #2: Seasoned team, high confidence between members. On these cases, there's no better "communication" than working software. Nothing else needs to be written.
===
Remember: Everything that's not directly contributing to delivery, is a waste. Oftentimes, wastes are needed, but a team doesn't need to stick to them for the sake of the methodology. A methodology is just a mean, a tool for a purpose, not an objective in itself. Your focus should always be on the consistent delivery, not on consistent methodology usage.
Jira is not a communication tool, but that doesn't mean you can't add information gained elsewhere to a ticket.
If something is unclear in the ticket description, by all means ask around until you understand it, and then come back and update the ticket description. If your conversation unearths missing acceptance criteria or a link that would be relevant to anyone who implements (or just looks at) a task, go ahead and add it.
Note that while you can use comments to have a conversation inside a Jira ticket, a long comment thread can easily get out of hand. It's also easier for comments to go out of date than a description (which can be updated by anyone). Comments are a good way to get someone's attention, though, and to get specific questions answered, for example when you need more details about a task or bug report.
First and foremost, you can't use tools to solve this. If there is any problem here, it's a people problem and a communication problem. I say 'if' because this may be fine. Maybe it's something that really only effects them. Or maybe they are, after their 1-on-1, sharing the info with the right people.
If you are seeing impacts where info isn't being shared from those conversations and it's impacting how the team works, my best recommendation would be to raise those impacts at the retro and then as a team, discuss how you'd like to work differently to avoid those impacts. If they are using other tools instead of Jira, maybe Jira is a poor tool for that communication, but other options exist, like having the slack conversation in the team chat instead of 1-on-1. I'm confident the team can find the solution that works well for them, makes communication easy, and avoids accidental side-effects.
Tiago's answer and Llewellyn's answer both give good perspectives on the overall approach. However, I'd take a slightly different approach.
Since Jira tends to be more accessible than an individual's email inbox and private Slack channels or DMs, I tend to think of Jira as the source of truth and use integrations to allow people to push content into Jira when it's appropriate.
What you should consider is a way to get information out of these other tools and into Jira. Fortunately, Jira has integrations for email, Slack, Teams, and other tools that can help to either link content to the Jira ticket or get content attached to the Jira ticket as attachments or comments. The integrations with Slack, for example, allow people to receive issue notifications and make certain edits, including leaving comments, without leaving Slack. There are similar integrations for Gmail and Outlook as well as more generic emails to and from Jira.
What to do when the team prefers private communications on mail and chat over collaborative tools like Jira?
You're conflating collaboration with transparency. They're two different things. Your team is collaborating. What you're really asking about is how to make the results (if any) of that collaboration visible.
Use your ticketing system for ticket management and progress reporting. Don't try to repurpose it as a communications tool, which it is not what it was designed to do even if a particular system has some limited comment or email features bolted on.
As a ticketing tool, jira is absolutely not an effective method of intra-team communication. The Twelve Principles Behind the Agile Manifesto clearly states a few key things (emphasis mine):
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
You should trust the team to be collaborating together effectively. Unless there's a clear dysfunction in their collaboration, you should be supporting their collaboration rather than trying to micromanage how they do so.
This doesn't preclude you requesting that the team members make useful results visible to the rest of the team using whatever information radiators are most effective. However, it still differentiates between the collaboration itself and the visibility or dispersion of useful information that may result from the collaboration.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
This is true prima facie, but it doesn't mean that other forms of conveying information lack all value. However, there's generally a hierarchy that needs to be adjusted for your working environment.
Face-to-face provides the highest level of interpersonal communications bandwidth. That's not always practical for non-colocated teams, or for teams with neurodiverse team members, so you can make trade-offs here. In roughly descending order, communications bandwidth still has value when videoconferencing, on the phone, real-time chat, asynchronous chat, code comments/issues, email, and (deliberately dead last) ticketing. For intra-team communication and collaboration, support whichever options give the most bandwidth without preventing the team from collaborating in the ways that they find most effective.
Your real issue seems to be either:
The a priori assumption seems to be that Jira is the best place for this information to be made accessible to the rest of the team, but that's not necessarily the case. It's a faulty assumption.
The real questions you should be asking are:
Do these collaborations have any impact to anyone but the collabaorators themselves?
Assuming the software development domain, pair programming is a great example here. Tight communication makes for better pairing, but no one else on the team needs to be a party to the ongoing conversations. They just need to be aware of material changes to the code base, especially if they will need to rebase ongoing work-in-progress on top of changes merged to the integration branch.
From a Scrum perspective, you don't need to report the minutes from every casual conversation or even deliberate collaboration that takes place. The only thing that needs to happen is that the Scrum Team as a whole feels like they're coordinating effectively.
What should happen when collaboration results in action items or material information for the whole team?
Action items should be placed on the Sprint Backlog, or possibly handed to the Product Owner as future Product Backlog work. Other information that affects current product development should be automated by your source code management (SCM) system, team wiki, or your ticketing system when changes are made.
In other words, use your SCM, Jira, or other information radiator to inform the rest of the team when something in the environment that matters to the team has changed. This could be part of the definition-of-done for user-stories or features, or communicated during the daily-scrum.
What's your interest in the details of the conversation as a scrum-master?
The role of Scrum Master has certain key accountabilities, but taking minutes or structuring every working collaboration isn't among them. Unless there's clear dysfunction, or you're addressing issues brought up in a Sprint Retrospective, you're doing more harm than good in trying to dictate how the team communicates and collaborates while building the Increments that achieve a Sprint Goal.
Not every meeting or conversation is of interest to the whole team. Trying to account for all time spent in meetings, conversations, or collaboration is also a Scrum anti-pattern. So ultimately, unless this is creating information silos within the team, you should absolutely butt out on this issue.
If material information is not being disseminated or routinely preventing the team from meeting Sprint Goals, then of course you should bring this up in a Sprint Retrospective. You should then collaborate with the team to identify a better way to share out decisions, action items, and material changes that might impact the team or the current Product Goal.
In short, your objective should be to let the team do whatever works best for them so long as Sprint Goals are being met. How they are being met is up to the self-managing members of the Scrum Team as a whole, so unless this is causing some kind of pragmatic problem for you as the Scrum Master or for the project itself, there's absolutely no upside in trying to funnel communications through a ticketing system. There are, however, many downsides to that approach.
Use your ticketing system for ticket management and progress reporting. If you need additional tracking, discuss it with the rest of the team. However, under no circumstances should you ever replace direct interpersonal communications with ticket-status updates.
