My team is ignoring me as a Scrum Master

Hi Mustafa,

Is this a new process or have the team been working this way for a while? 

I could be wrong but I think I'd go back to basics and almost forget about Jira - the system isn't important, it's getting the stories and tasks 'done' that matters.

• Are your team on track? 
• Do they understand the goal of the project and what do they need from you to be able to achieve that? 
• Are they distracted and being sent in all directions? 
• Do they understand the process or did they nod during the meeting but didn't take away a clear understanding?

These are the sorts of things that you'll be able to tease out of them in the daily Scrum meetings.  By being part of that discussion rather than setting rules and dictating, you may be able to help them achieve what you're looking for and they'll be able to communicate any obstructions/distractions that you or a fellow team member can help with.

What value would this tool give them that they are not currently getting, and are unable to see?

Unfortunately, many companies are hiring tool-administrators and tool-evangelizers and giving them the Scrum Master or Agile Coach title. This is where you're likely stuck.

Is tracking in this tool required by management? If it is, you have no choice but to continue to reinforce that this is required (by management). Don't take it personally if some people take time to adopt this new business process. But your key responsibilities should be much broader than being an alarm clock for the team. You can make or break Scrum for them. Are there bad actors at play here? Do your best to work one-on-one with the agitators. You should get formal coach (not "Agile Coach") training to help build this skill. 

Worse case, this is a business and you may need to escalate. Scrum or no scrum, if management requires its workers to do something, they can't just self-organize around not doing what they're being paid to do. 

Individuals and interactions over processes and tools. JIRA is a tool. Find out what the actual added benefit would be for the team, what problem it is that the organization is trying to solve with it and if this can be done a way that would suite the team better.

For starters, I suggest you quit calling yourself a Scrum Master and start calling yourself a Project Manager.  Because from your description that is exactly what you are doing. The process you outlined does not involve a Product Owner, a Product Backlog or self-organization.  It sounds very much like you are trying to manage to a timeline with a list of tasks. You are managing with a command-control method instead of leading with a servant-leader mentality. All through your post you are telling, managing, or dictating.  You are not allowing the team to decide anything.  This quote from the Scrum Guide keeps running through my head

They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

You said

We're a good team and everyone is respectful to each other but when it comes to Jira, I can't make them anything. 

It seems like the Development Team wants to self-organize but you are trying to force them to work in a specific way. If they are a good respectful team, maybe you should ask them why they are not willing to do the work you are trying to force them to do.  And out of respect for them, you should adapt to their feedback.  However, as @Mark Adams mentioned, if the company is requiring this then you should be involving the management levels to force them to do it.  Or maybe you could be a Scrum Master, talk to the team about how they would like to work in order to be most effective and efficient, then talk to management about how their desire to force something on the team is negatively affecting the team's ability to produce value. 

In addition to what has been said already, one major thing you have failed to mention is the reason behind entering the information into JIRA. If the team understands the value that is given to others by entering information, it typically results in a willingness to make it happen. Being told "you have to enter this item into JIRA and put a due date in there" is not going to get results. You need to understand the reasons behind this information being entered, validate that it is in fact valuable, then explain to the team. 

Speaking of Due Date, I'm hoping that you're using the last date of the sprint and nothing else for that date. Truly, I would encourage fighting back against adding any kind of date in there but if nothing else enter a date the is the end of a sprint, not in the middle or anything else.

explain the reasons why JIRA updates are important and then start sending reports on a daily basis. You may see some improvements

These are all great answers.  Getting frustrated because a Scrum Team won't use a specific tool?  Time to look at the core essence of Scrum.  I think the OP could benefit from reading up on the Scrum Guide definition of Scrum Master and memorizing the Agile Manifesto. The impact to the team isn't going to be their refusal to use a certain tool in a certain way.  It's going to be the fact that the person in the role of Scrum Master isn't following the Scrum principles.

It is interesting to hear a Scrum Master who is concerned he/she is not being heard by the dev team. As a Scrum Master my job is not to tell the team but to inspire them to go beyond greatness. If they're ignoring me, maybe they know what they need to do as mature adults or maybe I am not inspiring enough for them.

Really interesting answers here and I am inclined to agree with them.

Something else came to mind, have you found out from them if they can actually use Jira. Sometimes, SMs assume that everyone in the Dev Team can use Jira, they might not know how to use it. Also, when you tell them to 'do' something, which you are not supposed to do anyway, do they actually understand what it is you want from them? Sometimes things do get lost in translations. Have you called them aside individually to understand why it is exactly they have not delivered anything? You need to understand them as much as they need to understand you.