Navigating Jira | ACA-900
Learning to navigate a system is crucial to using it successfully
Navigating a system isn’t something I commonly think about, especially when it’s one I’ve been using extensively for over a decade. That said, learning how to move around a system is incredibly important, and Jira is no exception.
New UI Incoming
One of the advantages of cloud-based software is updates can easily be made to the system and rolled out to everyone… and one of the disadvantages of cloud-based software is updates can easily be made to the system and rolled out to everyone. As of writing Atlassian will be deploying a new user interface (UI) to Jira and Confluence in the next few weeks. At its core it shifts most of the navigation bar from the top of the screen to the side. Personally I’ll find this frustrating in the short term as
Check out this video for more on the UI, but I highly encourage you to try it out before it becomes the standard. This is also something you should tell your team about as others you work with will likely be (more than) confused when everything suddenly shifts to the left.
Navigation Bar
The navigation bar is found at the top (old UI) and side (new UI) of your screen and contains a number of useful menus.
Site/Product selector - This menu lets you switch between products (e.g. Jira to Confluence) or sites (If you have access to multiple sites). I use this frequenrly to move between my work instance and a test instance.
Home page - Clicking the Jira logo brings you back to your home page, a very useful trick! Personally I don’t use this much, but it can help newer users get re-oriented if they get lost or don’t know how to get back somewhere.
Projects - This menu lists the last few projects you’ve visited and keeps your Starred projects at the top.
Filters - Lists the last few filters you’ve used, along with any you’ve starred.
Teams - Lists any teams you’re on and lets you add new ones. I don’t use teams too much, but they let you do things like @ mention a group (but not assign to a group!).
Apps - Lists any apps your instance has, and links to the marketplace. This is something I check any time I end up in a new instance as their add-ons can differ from what I’ve used it.
Finding Boards
Boards are a central part of using Jira Software for many teams. They live under the project in the new UI (which is a bit different from what we’re all used to!). Navigating within a board is fairly straightforward - work items are organized into columns, which include 1 or more statuses. Work items can be dragged into new statuses that update the underlying work item.
Starring Items
A useful feature for navigating is to star frequently used projects, filters and more. This is similar to bookmarking a page, and makjes it easy to find frequently used information. I encourage my team to star the things they use on a regular bsis to make them easy to find. Starred items appear at the top of menus, and can easily be un-starred by clicking on the star again.
Keyboard Shortcuts
There are a number of keyboard shortcuts available in Jira, and while they’re not required learning, they make it a lot easier to use Jira. Personally I’ve memorized a few (and need to learn more!), but know I can always find them by hitting the Shift key and the ? key at the same time. This will bring up the list of all shortcuts, and give me the option of disabling shortcuts all together (although I don’t know of anyone who’s done this).
An important thing to know about shortcuts is that some are dependent on the screen you’re on. For example, when you’re on a board specific shortcuts work, but not when creating a ticket. This makes this a bit more complex to learn, but taking time to figure them out can be a huge timesaver (plus makes you look extra knowledgable :D).
Conclusion
While navigating a system seems like a simple thing it is an incredibly important skill. I find this to be especially true if you’ve never been taught how to do it (like me!). While you will figure things out, you’ll likely miss a lot (for example I didn’t know how to find the keyboard shortcuts for years…).
Check out the full recording below and I look forward to seeing you in a session soon!
Permissions and Roles | ACP-420 Jira Service Projects
Dive into permissions and roles!
Aren't time changes fun? Apologies to the folks who missed any/all of session 5 due to the time change... Luckily we have about 6 months before we get to do it again! (recording below if you missed out!)
Session 5 dug into permissions and roles. Personally I have to handle questions related to these topics on a weekly (sometimes daily) basis, so they are close to my heart. This also takes up 14% of the exam (but feels like half of my day sometimes!).
Check out the info below for more about what we covered, including the FAQ that folks had.
-
Before we get into how they work, you'll want to consider why you need them. It's very easy to dig in and start building roles or schemes. Resist the urge! Instead, step back and talk to your team and stakeholders about what is needed. I start by understanding the types of people who will be using Jira. Examples include agents, auditors, managers and the like. This is essentially building your list of roles, which will be useful when you start building.
Once you understand the groups you can determine what they need to do. For example, some groups may need the ability to respond to customers, while others should only be able to view tickets. This mapping process can feel arduous, but is an important step in understanding your teams needs.
This can take a while, but at the end you'll have a blueprint of what you'll go build. This makes it much much easier since all you'll have to do is push the right buttons - all the hard part (the thinking) is already done.
-
Permissions are layered, like an onion! On a day-to-day basis I regularly only interact with these at the Project level, however, as admins we need to understand what falls into each layer, and be ready to troubleshoot issues that can span levels.
Organization - At the top is the organization level. This layer control things like the ability to @mention, or access the instance.
Product - Next comes the product - e.g. Jira service management. This level mainly allows you to manage who can use the product in your org.
Project - Next is project level. This is where most folks will have access as it allows you to be a project admin. Here you can control things like roles, customer access and the like.
Issue - The last level is the issue layer. Typically I don't see this level being used as it adds more complexity and most of the time you don't need to lock issues. That said for environments with sensitive data (e.g. hr, finance etc) locking issues is important.
While there aren't 'gotcha' type questions on Atlassian exams, we do need to be careful and understand nuances to access. For example, 'assignable' and 'assignee' are both required permissions to be assigned a ticket (the first allows you to be assigned to a ticket, the second allows you to assign a ticket). Nuances like that are important for the exam, but also as a an admin to support our teams.
Some nuances we should keep in mind include:
Jira Admins are determined by who has access to the “jira-admins-(sitename)” group, or assigning a user to the Jira Admin product admin role
“browse users and groups” lets people @ mention users, select users from picker fields, share issues and see names. It does not prevent folks from assigning issues (I ran into this at work recently!)
“Browse projects” is the most important permission (according to Atlassian! :D) as it determines who can see a project and issues… without it you can’t see anything, regardless of your other permissions.
In order to edit due dates and rank issues you need both schedule issues AND Edit issues
Service project agents only applies if you’re in JSM
Some perms can be disabled globally like liking, watching and voting.
-
I think of roles as types of people that work in Jira. There are four roles that come with Jira, and we can't remove them - admin, agent, collaborator and customer.
Confusingly team and company managed projects have different names for them…for example 'agent' in team managed and 'service desk member' in company managed.
That said each role contains the appropriate permissions for those types of people. Agents, for example, can open and edit tickets. Collaborators can open, and post internal comments, but not edit. As an admin in a team managed project you can edit roles, but jna team.managed project you can't (unless you happen to be a Jira admin too).
We aren't, however, stuck with just the roles were given. We can create new ones. This may require a Jira admin, but once they're created project admins can assign them to people, which indirectly allows project admins to control permissions. These roles can be incredible useful in meeting needs of your team, which makes understanding what they need to do and why even more important.
Next week we'll get into, looking forward to seeing you there!
FAQs
Why are roles name differently in Team and Company managed projects?
I have no idea! It is a bit confusing though…
How can project admins manage permissions in Company-managed projects?
They can indirectly manage permissions by assigning Roles. This is where it’s important to have a good relationship with your Jira admin so they can partner with you to build Roles that make sense for your team.
Why is “schedule issues” necessary to re-order issues on a backlog board?
This is a great example of a non-intuitive thing we have to just know. From what I understand it has something to do with how Jira stores rank order information… does it make sense? not really… Do we need to know this to help folks? yup.
Check out the session recording here