Jira Service Management & Incident Management | ACP-420
A major use case of Jira Service Management is tracking incidents - learn about how it’s done here
When people think of Jira Service Management they tend to focus on supporting customers and intaking requests for IT things. That, however, is not the only use case for Jira Service Management. Another major use for it is to track incidents.
What is an incident
Incidents are the source of what causes a disruption, they’re not the symptom. For example, if a server goes offline, reports of not being able to access aren’t an incident (They’re a problem). The incident would be the source of the issue - something was unplugged, or a bug in the code cropped up.
While organizations can classify incidents differently (typically by how many customers or users they impact) for the purposes of the ACP-420 we’ll consider “Incidents” and “Major Incidents”. Major incidents tend to impact broad groups of people, or bring entire systems offiline while “incidents” impact smaller groups, or disrupt, but not stop, systems.
Why track them?
While we tend to think of incidents as something that only impact software teams, incidents are a fact of life, and every type of business, team and group will experience them. Finance teams may experience an incident when an account has more or less money than expected. Marketing teams may experience an incident when a campaign fails to publish properly. HR teams may experience an incident when a wave of resignations occur.
Each incident represents a failure point - and an opportunity to learn and become stronger. This makes them both something that must be responded to quickly (to mitigate damange) and a very valuable learning opportunity that can help the team grow.
Tracking them in Jira Service Management offers a number of advantages beyond just keeping track of them.
It’s in Jira - This may be obvious, but keeping your incidents in Jira Service Management means they’re in the same system as your other work items. This makes it easy for a team to inveistgate root causes, other reports of issues and related topics as all your information is in a single spot.
Source of Truth - tracking incidents in Jira Service Management ensures everything related to that incident is in one spot. This means your responders (the people who determine what happened and fix it) just need to open a single work item to get everything they need.
Who’s involved?
There’s typically a few folks involved in incidents:
Incident Commander - this is the individual who is solely responsible for managing the incident. Typically they’ll be someone who is familiar with the technology or process, and is able to work with others to resolve issues.
Responders - Responders are individuals who will be pulled in to help resolve incidents. Depending on the incident this group can differ as different skills or backgrounds are necessary.
Customers - Customers are also, indirectly, involved with incidents. Typically they will be the ones reporting them, but they will also be impacted by them. This means the team needs to keep them updated (even if only at a high level) about what is going on.
Communication
Communication is incredibly important during an incident. Responders will need information on what’s going on so they can solve things. Customers need to be updated on when things will be back to normal. Stakeholders will need reassurance that things are moving forward.
Jira Service Management offers a number of tools to help with this, but when an incident occurs we should also consider other ways of sharing information.
Options within Jira Service Management - note that these require careful thought and configuration to ensure groups are getting the information they need, when they need it.
Notifications - incident tickets can be setup to notify specific groups when updates are posted or statuses change. This automates some communication as specific groups will get those updates with no extra effort.
Automations - Automations can be used to send additional information - via email, instant message or more.
Announcements - Admins (and sometimes Agents) can setup announcement banners on Help Desks and Portals. These help inform customers about known incidents and set expectations on when things will be resolved.
Options outside of Jira Service Management
Email - Email is still a very important communication channel during incidents. I use this for longer updates and to direct folks to other resources.
Instant messaging - Slack, teams and other platforms offer ways to communicate quickly and widely. I like this for quick updates.
Operations
Up until recently a tool called OpsGenie would help teams respond to incidents. Atlassian recently rolled this tool into Jira and is calling it Operations. This is an optional feature that needs to be enabled for a Jira Service Management Project, but allows teams to manage their response to incidents by doing things like:
Setting up on-call rotations - Typically team members will be “on-call” for a period of time. This means if an incident does happen, they get alerted via email, text, slack, carrier pigeon and the like to respond. Exactly how these rotations work varies by team, but they are critical to a succession repsonse.
Escalation paths - If the person on-call doesn’t respond to the alert within a time period (e.g. 5 minutes) someone else can be designated to respond. Typically this is the next person on call or the entire team, but can be (almost) anyone in Jira. This helps ensure that someone jumps in and begins work.
Alerts - Alerts are messages (either from a person or an automated system) that something might be going on. Alerts are used to flag potential incidents, but need to be acknolwedged and managed to ensure they’re actually acted on.
Stakeholders & Responders - Incident tickets can have Responders (people who are expect to act on the incident) and stakeholders (individuals who need to be informed of what’s going on). These are optional, but make it substantially easier to communicate what is going on during the incident - and to identify who will fix it.
Post Incident Reviews
After an incident is resolved teams need to take time to review what happened, understand the fault and ensure it doesn’t happen again. This isn’t about assigning blame, but rather focused time to improve the team, process and system.
Typically this is handled in Confluence, however, there is now a “post incident review” feature that can be flipped on for incidents. This helps the team focus their information on the incident, making it easier to track (since it’s directly on the ticket) and easier for the team to gather (since they don’t have to go anywhere else).
This feature adds a button to Incidents called “add post incident review”. This creates a related Task to help track the review. While this can be done on the incident ticket itself, I appreciate that it is split off. This allows the team to focus on solving the problem (e.g. the incident) or on review it (the PIR). Splitting off the information also lets you link additional resources that may only really relate to one or the other. Personally I also appreciate how it consolidates information in Jira - meaning my team doesn’t have to go open other tools to figure out what happened.
Conclusion
There is a lot in Jira Service Management that helps support incident management. From setting up on call rotations to informing stakeholders to tracking related work items. Atlassian Learning also dedicated 90 minutes to this (most other sections got 1 hour, max) so this is definitely an area to dig into.
This session was split across two weeks - check out the recordings below!
ITSM Projects & Portal Configuration | ACP-420
A major use case for Jira is to support IT Service Management teams
This week we’re digging into how to configure Jira Service Management (JSM) to support ITSM (IT Service Management) and how to configure the customer Portal.
Whats ITSM?
At a high level ITSM is how information technology teams set themselves up to support their customers. This includes everything from determining what processes they need to use, to how they’ll setup Jira to what types of tickets they’ll take to what SLA’s they’ll have. I find this to be one of the more common use-cases for Jira, although groups may not call it “ITSM”.
The Portal
Each Jira Service Management project has a portal that allows customers to put in tickets. Typically this portal is only available for internal customers via a specific link - but can be exposed to external customers as well. The portal contains request types, which may be put into groups. For example anything related to requesting or fixing hardware could be found under a “Hardware” group (note that request types can be added to multiple groups!).
Portals can be grouped into Help Desks. By default every instance has a single help desk which contains every portal, however, you can create additional help desks as needed. The help desk is intended to be the one place everyone knows to go to when they need help as typing something into its search bar will bring up things like:
Confluence content that related to the search
Portals that relate to the search
Specific request types that relate to the search
It’s important to keep in mind that the help desk’s ability to search is limited by how well the underlying content/information is setup. For example, if your Confluence space it’s structures well and articles don’t have relevant titles customers won’t find content easily.
Both portals and help desks can be branded (the first by project admins, the second by Jira admins). THis is something I highly recommend doing for every portal as aligning the look and feel with your corporate brand makes it easier for folks to use it (after all if they find a portal that has different logos and colours than they’re used to they may think they’re in the wrong spot).
Portals and help desks can also have announcements - basically a banner at the top that can be used to share information. Common examples include information on system outages, company events and other information that everyone should know. Project admins and Jira admins can edit announcements on the Portal and help desk, and you can optionally allow agents to update announcements at the portal level. Note you can’t specify which agent, any agent will be able to do this.
ITSM Support
The first thing any group should do when using Jira Service Management to support ITSM is to ensure they understand their internal processes and policies. Failing to do this will result in a setup in Jira Service Management that doesn’t quite fit - and will need to be rebuilt. Once that work is out of the way, however, Jira provides a number of features to support ITSM.
Request Types & Forms
Request types allow teams to tailor intake to specific things. Many IT teams will have a (relatively) fixed menu of what they support, which can be expressed as various request types. Depending on the teams need, these request types can be restricted (e.g. only VPs and above can use the “Executive Help” request type), or tweak to fit specific groups.
Forms allow groups to collect additional information on request types - and they don’t require a Jira admin to setup. They also offer a number of formatting features (similar to Confluence pages) which enable teams to create more appealing looking forms to solicit information. Forms can also be filled in after a ticket is submitted, allowing agents to collect additional information as the process continues.
One practical thing to be aware is that forms do not auto-expand on tickets. This means that when an agent opens a ticket, they won’t see the entire form. Instead they’ll get a line indicating there is a form that they’ll have to click on to use.
Notifications
Notifications are sent by Jira around specific events, for example, when a ticket is created. There are a number of default notifications that let folks know what is going on, however, it is always worth the time to take a look at them and adjust them as needed. This could include changing the terminology used to match your organization’s guidelines, or even adjusting the template (with HTML and CSS) to match your branding.
This seems like a small thing, but having tailored communications can have a huge impact on your customers, and their perception of your team.
Conclusion
The Portal is likely the first thing your customers interact with when using Jira Service Management - so make time to tailor it to your needs. Additionally, take time with your team to understand what they need to do, and what processes they need before you start setting up Jira Service Management and you’ll save yourself a lot of headache!
Check out the video below and hope to see you in a session soon!
Configuring Fields in Company & Team Projects | ACP-420 Jira Service Projects Study Session #7
Learn to configure issues and notifications in Jira Service Management
This week we continued our exploration of configuration, focusing on issues/work items and request Types, and this is another area that project admins will have a split experience in.
Team-Managed Projects
Team managed project admins can do basically anything they want in terms of issue type setup (note that technically there are only request Types in team managed). This is good for smaller teams, or in cases where a project is a one-off. Not having to go through a Jira admin and modify schemes (or add new ones) is a massive time-saver, and also frees up the Jira admins to handle bigger, more complex challenges. That said, it’s also a bad thing, as you might quickly end up with multiple team-managed projects floating around that all require administration… and due to how they work there’s no single way to manage them all.
Team managed project admins can, however, add new request Types at any time. This gives them a ton of flexibility to quickly spin up new request types on demand. They can also make any changes they want to the fields and workflow (well dig into these next week) they want to. This includes recording fields as displayed to the agent (the issue view) and the customer (request view). Company-managed project admins can do this as well, however, it is important to note that these are spread across different tabs (“Request Form” and “issue view”) in company-managed projects, but they’re on a single screen in a team-managed project.
Company-Managed Projects
Company managed project admins are much more limited in terms of what they can change. They can manage request types (including making new ones), but can't make new issue types, add fields, change screens or modify workflows. Also, any request type they create has to be linked to an underlying issue-type that’s available to the project (via the issue type scheme). This, in turn, limits the available fields to what’s connected to those issues types. This makes them entirely dependent on a Jira admin to help with updates. (Although they can't make these changes, understanding what is needed is very helpful as it makes it easier to file a request and work with a Jira admin to make those changes).
Company managed project admins can, however, control what fields are displayed on the request (as long as they're available on the underlying issues). They can also change the display name (what a customer sees) to make the experience a bit easier. They can also change the display name of workflow statuses, which seems like a small thing, but can have a bit impact on someone's experience.
Next week well pick up with emailed requests and then dig into knowledge bases and workflow setup! After that there's a week break for TEAM25 (if you're going let me know, I'd love to connect there!).
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
Project Type Showdown, Request Types and Queues : ACP-420 Study Session #3
ACP-420 session three is in the books (embedded at the bottom of this page too)! We picked up right where we left off with team vs company managed projects, and got through setting up queues (more specifics on those topics below).
Study Tip
If you're in my sessions have a Jira service management instance up and follow along live. This will let you see the concept, but also uncover questions you may have and ask them live.
Topics
-
These two project types certainly bring up conversation! While both offer the ability to collect and manage tickets , they differ quite a bit on the management side.
Team managed projects let the project admin adjust almost everything. You can add request Types, change workflows, add fields and more. This gives smaller, less technical, teams a lot of flexibility.
Company managed project, on the other hand, have a wider array of features, but limit what a project admin can do. You can still make request Types, but can't modify workflows, fields, screens, notifications or access. This is because company managed projects use schemas, or shared configurations. Schemes let an orgnaization share configurations across projects, vastly simplifying administration.
There is some debate about whether groups should ever use team managed projects (ill dig more into this in a future blog post), but for the ACP-420 we are expected to know the differences.
-
Request Types are customer facing forms that let customers out in tickets. Project admins can set them up and modify them as needed, including things like hiding fields, grouping in the portal and having more customer friendly field names.
In a company managed project these are all tied to an issue type, which provides the workflow for the request type.
In a team managed project there is no issue type, so each request type has its own workflow, fields and more.
-
If request Types are how customers enter tickets, queues are (one of) the main ways agents interact with them. Queues are essentially saved searches that project admins manage to guide agents on which tickets should be solved.
Agents can select queues to view, but only project admins can edit queues. This means that we, as admins, need to take time and effort to craft queues that best support our teams. Admins can do things like
* Define the tickets in the queue - this is done via Jira search (basic or jql) and can be refined at any time
* Define what columns are displayed and in what order - this allows admins to tailor what information is easily access access
Queues can be grouped into 'priority queues', basically groupings project admins select. This helps further guide agents by helping them work in one spot and not having to jump around between parts of Jira.
Questions
Why would anyone use a Team Managed project?
It gives teams more local control of their project and removes reliance on a Jira admin (something many company's don't have, or have in limited supply).
Why would someone NOT use a team-managed project?
Eventually many teams outgrow a team-managed project or need more support so they need to be converted. This takes time and effort, which can be avoided if you just start in a Company-managed project.
What is a “Jira-ism”?
Anything that makes you hang your head in disappointment over decisions Atlassian makes that common sense would tell you could have been implemented in a much better way
Where can I get a recording of the sessions?
When I go into Project Settings why does “request type” not appear?
Request types only exist in Service projects, so you’re likely in a Business or Software project if you don’t see Request tyeps
What is a PICNIC?
Problem In Chair, Not In Computer
(Note - this won’t be on the exam!)
Why would I hide a request type from the portal?
I do this to let my agents enter specific types of tickets but not customers, for example “hardware request” could be something only agents can enter after they think new hardware is needed.
Why should I bother changing the request type icon?
The icon helps differentiate request types and makes the customer experience a bit better
It also makes it easier for agents and admins to differentiate tickets easily
What it means to be a system admin
Being an admin is about much more than getting more access - it’s about leading your team to something better.
I ran a live training recently about being a Confluence Space Admin. In the context of Confluence, a Space Admin has specific privileges to do things like control access to a space, modify features, etc. The session covered the technical aspects of what admins can do (e.g. features to help manage everything, access controls, etc) but also discussed a more important topic to me - the non-technical responsibilities of a system admin.
Non-technical importance
Frequently I find that individuals forget about the non-technical side of being an admin… after all, it is very exciting to get admin access to something. It means you get something special, something extra, that most folks never get. It also, however, means you accept a large responsibility - ensuring your system runs effectively and supports its users.
Personally I’ve been caught up in the excitement of being given extra access. There’s new buttons to go push, new things to learn and a big sense of power. Depending on the system the amount of power can be on the smaller end (resetting passwords and the like) to extremely sensitive (access to home addresses or social insurance numbers). Being an admin means being trusted with that access - and by extension to power and responsibility that comes with it.
The best advice I was given about being an admin was in the context of managing a human resources system that had social security numbers (United States government ID numbers). The senior admin told me that “Our job is to make sure the numbers are correct, not to use the numbers”. This had a huge impact on me as it highlighted the importance of making sure the system was accurate, regardless of what the information was.
“Our job is to make sure the numbers are correct, not to use the numbers”
For me this is what is important about being an admin. You don't only need to consider what the system does (serve up info, support collaboration, etc) you need to understand why you need to do those things and keep an eye on everything around the system. This includes things like planning, maintenance and leadership. Typically one, or all, of these things is forgotten, resulting in systems that are 'broken' (if you ask their users).
What should admins spend their time on?
For me, admins should be spending most of their time planning out how their system can be successful. This doesn’t mean we ignore the tools or features we have, but it does mean we think about the best way to use those tools to help our team. It also means we have to understand what our team needs to do and why they need to do it. For Confluence this could be thinking through an optimal structure, or figuring out what content is missing and how to get it. That said, it also means understanding what our team is trying to accomplish. For example if they need to onboard new hires they’ll have different needs than if they need to support customers.
Maintenance is another area that admins need to be very active in. It's not glamorous, it won't win awards, but it will ensure your system supports the people using it and that it is relevant to them. Maintenance means regularly review how the system is used, digging through content to ensure it’s updated and similar activities. In my experience most of the complaints about Confluence not working related to stale or content that is hard to find - two things that fall squarely on admins to manage.
Active Admins
Being an admin isn't a passive job (although it's easy to fall into that mindset!). Instead admins need to be active and lead their team in how their system is used. In general this should take the form of getting training on the system, reading manuals and talking with your team. For Confluence this can take the form of training users in best practices, building onboarding documentation and showing folks how things can work.
There is a lot that goes into being an admin, and it's incredibly easy to think it's only about the technical side or things or the extra access. For me, however, being an admin is a privilege and a burden. Admins enable their teams. Admins keep things running. Admins allow others to excel.