Atlassian Jira Tips: Setup and Getting Started

Getting Started with Jira

Like many other products, Atlassian Jira comes with a manual. Similar to other manuals, this one is long and exhaustive. Reading a manual from cover to cover can be quite exhausting. If you’re thorough or have a passion for reading manuals, Confluence.atlassian.com is your source for the entire Atlassian product suite instructions, especially Jira. However, if you want to hit the ground running and know the quick hitter tips that will immediately help you with Jira out-of-the-box then continue reading. In this blog, we’ll provide valuable tips and recommendations on what you can do to make your initial Jira experience seamless.

Project Shared Configurations

Applying uniform settings to projects creates a culture of transparency, and guides users to know what to expect when navigating from project to project. When the user creates their first project they are prompted to fill in a few fields and tick a few boxes. One of the boxes they have the option to check is “Share settings with an existing project”.

According to Atlassian’s documentation, projects that share configuration share:

  • Issue Types
  • Workflows
  • Screens
  • Fields
  • Versions
  • Components
  • Permissions
  • Notifications
  • and more

This can be a great time saver if you have many projects that will share all the same settings, but it can also have negative implications. If you change one of the settings (listed above) in one project it will then change the settings for all the projects that share that configuration. Therefore, we recommend establishing a strong governance process and choosing this setting early in your Jira adoption.

Since the developers, users, and administrators roles are all included out-of-the-box we will use these in addition to the ones that are created if you have Service Desk installed. The Service Desk roles are Service Desk Team, Service Desk Customers, and Service Desk Collaborators. We will only apply permissions at the role level.

Note: We don’t mention the “Atlassian Add-ons” role because it should be granted for all permissions except delete issues.

User Management

Managing users in big organizations can become a full-time job in and of itself. In order to reduce the time and effort spent to manage users, we recommend placing similar users into groups in your user management section of your instance. This lays the foundation and makes it easy to create new projects and spaces by simply giving permission to the group that needs to see the content displayed in the project.

How do you determine which users go into which group?

Do you already have an LDAP set up with other systems? If you are deploying Jira Server, it will be useful to integrate this LDAP with your instance so that Jira imitates your other systems in terms of user management. If you are using Cloud, check out Atlassian Access. As an overall rule of thumb, follow the organizational structure of your company. Put all of the people from different departments into different groups. If someone works across multiple departments, you can put them in multiple groups. You can have an unlimited number of groups in your Jira instance, but try not to get too granular with your groups. If you find yourself only putting one person in a group, then the group is not necessary.

Permissions

While Atlassian advocates for an open working environment (this is the default permissions scheme), it will be more beneficial to only grant permissions to groups that need them. For example – If there is a marketing project in Jira, does the HR team need to see it? Probably not. However, does the product management team need to see it? Absolutely. We recommend applying the permissions in groups, then assign roles within the project if necessary. If you assign groups to different roles then you might be able to reuse a permission scheme (like the Perfect Permission Scheme) that grants access through roles. From an administrative perspective, it will be easier to allow access at a later time instead of revoking access.

Workflows and Schemes

As will be discussed in our upcoming Default Anti-patterns in Jira blog, the default Jira workflow isn’t a one-size-fits-all solution for your project’s workflows. Your workflow is something that should be thought through with proper iterations. Before you begin creating issues in a new project or Jira instance, take time to consider all the aspects you want to include in your workflow. Think through normal cases and edge cases to thoroughly understand how your team gets work done. Once this is completed, you are ready to associate your workflow with the right issue types and start creating issues.

For small organizations with a minimal number of projects, it’s best to apply shared configurations and a strong governance process for the team. In doing so will help the organization scale as it grows; It will be easier for admins to configure projects, new users onboard to new projects, and current users to understand the work process for each project. Each project can have different workflows associated with different issue types. Alternatively, creating projects without shared configurations could create many one-off workflow schemes, permission schemes, and issue type schemes. It is especially important to define your process before getting started with your projects. Once the tedious business analysis is done, you will reap the benefits of reduced administration time (for configuration tasks) and have consistency across projects for your users.

Filters and Dashboards

One of the great features of Jira is that anyone with access can create a filter or dashboard. Depending on the user, each person might want a specific dashboard or they might be happy with the one you create for them. Learn about your different user groups and create dashboards for them. You can share these filters and dashboards with necessary groups, or a given project to help these users find their work faster. You can also set up dashboards for the management team to keep track of their projects.

Creating Dashboards

Think about user personas when setting up dashboards and filters. What must they see? What should they see? And what would be nice to see? We recommend creating dashboards with a maximum of 6 gadgets since users are unlikely to scroll for important information. Think about the first two gadgets in the dashboard like the first page of a google search result, important information should be displayed at the top. (Who goes to the second page anyway?)

Reminders

If you don’t want to go into Jira to look for issues, have them delivered to your inbox. You can use filter subscriptions to serve as reminders by setting up any sort of filter and having it sent directly to you on a daily or weekly basis. Read more about filter subscriptions here.

Issue Types and Schemes

Jira Core comes with the following default issue types:

  • Task
  • Subtask

Jira Software comes with Jira Core and:

  • Story
  • Bug
  • Epic

Jira Service Desk comes with all of the above as well as:

  • Incident
  • Service request
  • Change
  • Problem

At its core, Jira is built on issue types. Workflows, screens, and fields are all based off of issue types. While workflows are a large part of what Jira does, they still depend on issue types.

It is possible to add more issue types and create your own, but before doing so, we recommend getting familiar with the Jira software you’ve deployed and then being aware of the different possibilities and options available.

If you do decide to create more issue types, begin by reusing as much issue type as possible. Recycling and reusing are highly advisable in Jira best practices. Having too many custom fields, schemes, and custom issue types can clutter your administration and slow down your instance.

The same rule for workflow schemes goes for issue type schemes. Creating one-off issue type schemes is not advisable because it will clutter your instance and potentially slow it down. This is customizable for a reason, but shouldn’t be different for every project. Use shared configurations for issue type schemes as much as you can. Even if a project won’t use all of the issue types in the scheme, it’s still appropriate to use that scheme since users will still find the intended issue types.

Custom Fields

There is a long list of default fields or system fields in Jira. Most of these fields will cover what you need to accomplish out-of-the-box. There are many different field types available to you when you first open Jira. The standard field types are as follows:

  • checkboxes
  • date picker
  • date time picker
  • labels
  • number field
  • radio buttons
  • select list (cascading)
  • select list (multiple choices)
  • select list (single choice
  • text field (multiple line)
  • text field (single line)
  • URL field
  • user picker (single user)

The standard field types should be enough to get started, but if it’s not, take a look through the advanced custom field types. If you can’t find what you’re looking for you can always add custom fields to the different screens and issue types in Jira. To locate advanced custom fields, create a custom field from the administration panel and select “advanced”.

Keep in mind it’s best to reuse and recycle fields for the same reasons it is for issue types.

Resources

Atlassian Jira comes fully equipped with everything you need to start managing your projects. If you find yourself searching for answers, the Atlassian Community is a great forum to find other users who might be experiencing the same problems. Additionally, the Atlassian Marketplace is the official market to find apps that extend and enhance Atlassian products. Lastly, if you’re missing a feature and interested in custom development, make sure to reach out to Atlas Authority for help.