ACP-420 Jira Service Projects Study Session #2 Notes

Big News

It looks like the ACP-420 certification is getting a makeover. This is good news, since it means the content will be fresh and relate to new features... but also has a few implications for us. The biggest one is we won't be able to sit the exam until after April 15th (meaning my goal of passing by April 1st isn't possible!). While this could be frustrating, it does give us more time to prepare - especially since new content will likely be included.

Topics Covered

We got through most of the topics I hoped to. Below is a synopsis of what we covered (all in my own words - definitely review the great free training in the University!).

Check out the full recording here

Core Features

  1. Issue types have their own workflow, and can have many request types

  2. Request types are customer-facing and are associated with one, and only one, issue type

  3. Workflows are the series of stages an issue type has, including transitions between them

  4. Queues are saved views of tickets that agents (people who work on tickets) use to keep track of what to work on next

  5. SLA's (Service Level Agreements) are time limits on tickets. These help agents prioritize tickets based on how much time is left.

Incident vs Problem

This concept appeared a few times, and is an important concept to understand in general (they’re also something I get mixed up quite a bit!).

  • Incident - something that happened. e.g. I see an error message, a website doesn’t work, etc. I also think of this as being the smoke a fire creates.

  • Problem - the underlying thing that caused the incident(s). e.g. a server was unplugged, there’s a bug in the code, etc. If the incident is the smoke, this is the fire.

Understand the different is important as we handle them differently. Personally I tend to see incidents well before problems - after all there’s a lot of users out there, so they tend to notice things first (although this isn’t always true!).

Use Cases

There are a number of different use cases for Jira Service Management. Honestly I’m not sure these will take up a lot of space on the exam, but definitely good to keep in mind as I bet some (or all?) may show up in your career!

Here are the use cases listed in the training course:

  • Incident management - Managing incidents

  • Problem management - Uncovering and resolving problems

  • Change management - Handling changes to systems or processes

  • Knowledge management - Keeping track of updates to knowledge articles/resources

  • Asset and configuration management - Assets are our computers/software, and configuration is how they’re setup

Best Practices

I appreciate these appearing so early in the course. Many times we get stuck on the mechanics of a system (how does an SLA work, how can I enter tickets) and forget all the things that happen around/before that part (planning, validating use cases, etc). The best practices provided by Atlassian relate to things like gathering requirements before you begin, keeping things simple (always a good idea!) and using naming conventions to make things easier to use.

Another best practice that really resonated with me was to test things before you deploy them. I’ve personally not done this (and suffered for it!) - so I highly encourage everyone to test everything before you deploy it.

The section finished up by reminding us to be Jira Champions - people who use Jira regularly and make it part of our regular practice and habit. This is easier said than done (and something I’m guilty of not doing all the time! :D). It is, however, a good reminder - even if we earn the ACP-420 certification it doesn’t mean much if we don’t apply what we learn and share it with others.

Overall I found that these best practices don’t only apply to Jira Service Management - they can be applied to any system or practice.

Map Business Requirements

One of the first projects I worked on spent months mapping business requirements. They had dozens of sessions to understand what the business needed, included subject matter experts from all over the business and had several people focused entirely on this step. It felt like overkill at the time, but once we got to deployment, things went really smoothly. This taught me the importance of understanding the business requirements, understanding what the system can do, and the importance of bridging the gap.

This section focused on exactly that - talk to your users, understand their needs, and then figure out what in Jira will help them do that. This can be easier said than done as there can be a lot of folks to talk to! Fortunately Atlassian has some basic questions to ask, and splits those questions up by group (individual contributor and managers). While this certainly sin’t everything you’d want to do or ask, it’s a great start in understanding what is needed.

There’s several important reminders in there as well - like not over-engineering, and making sure whatever you create actually meets their needs. (It can be very easy to forget deploying Jira is a partnership and not just us telling them what Jira will do for them!).

What we missed

I had hoped to talk about the differences between company and team-managed projects and just ran out of time! We spoke about them briefly, but we’ll pick up there next week.

What’s next?

Next week we’ll pick up right where we left off! I hope to get through the following topics - which should get us more hands-on!

  • Company vs. Team managed projects

  • Map business requirements to Jira configurations

  • Compare company-managed projects and team-managed projects in Jira

  • Choose a project template in Jira

  • Set up requests and queues

  • Set up your services in Jira Service Management

  • Configure SLAs to manage service quality goals

Next
Next

What it means to be a system admin