You can set up Jira to reflect how your team works or to influence how it works. Here's what I mean. When a team starts to use Jira, the first instinct is to configure it to match the processes and methods and language of how the team currently works. This makes sense because you want your team to go into Jira, especially early on in your use, and see something familiar. Issue types named for real work people do and workflow steps that reflect how actual work gets done on your team and field names that reflect names of things your team recognizes.
If you go into a sprint planning meeting cold, you know it can turn into a free-for-all, aimless meeting that will last twice as long as it should. After all, if your scrum team has been in place for even a few weeks, your backlog could easily have hundreds of issues in it. Maybe thousands. Going through a backlog this large in a sprint planning, without direction or a plan, can lead to an inefficient meeting that could include some members of the team chasing whims and subjective priorities, while others sit in silence wondering when the team will get around to talking about the tasks they will work on. This is no way to run a meeting.