So, if you haven’t noticed, we’ve had a bit of a theme going on here. Lately, I’ve been diving into various project settings and some tricks you can do with them. It’s serving us well, so I don’t see any reason to stop today! Given that, we are going to review a bunch of different project settings that, on their own, probably wouldn’t make a compelling article. So why not clump them together into an Omnibus!

A quick correction from Last Week!

However, before we get into that, I wanted to look back at last week’s article. No one is perfect, including this Jira Guy, and I made a mistake in last week’s article I wanted to call out. There, I provided a section on setting up a project to have different options for a field than the default. However, Maxim Grouchevoi pointed out my mistake on LinkedIn.

I went back and tested it, and he is correct! I don’t know if this is something new, and I remembered the way things used to work, or if I was always mistaken the entire time, but honestly, it doesn’t matter. I’ve corrected last week’s article with the new information, but I wanted to call it out here too. Thank you, Maxim, for taking the time to read my post and commenting!

So let’s get into the Omnibus and look and what we can configure within a Project!

Jira Versions

First, a quick note here, I’ll use both Version and Release here synonymously, as that is how Jira uses the words and how I’ve been trained to think of them. So if you see one or the other here, I’m talking about the same thing. 

The first setting I want to look at is a hold-over from when Jira was a Bug tracker. Software is often released in a discrete, well, Release. We’re all familiar with this concept, as Jira’s Server and Data Center products are still released this way. For example, I’m running Jira v. 8.13.1 on my test system currently.  

Given that, it makes sense that Jira would give you a way to organize stories and bugs using Versions. To see what’s set up for your project, You can either go to “Releases” in the project sidebar or go to your Project Administration Menu and click “Versions.”

“So…what?” you might be asking. Jira has moved on, and your teams might not be working in discrete releases anymore. To which I’d ask, “Are you sure?” I posit that even if your team isn’t working in named Releases anymore, I’m pretty sure there is some way to subdivide and organize your work. And that’s where this feature excels!   

For example, a previous team I was on would work in Quarters. So we’d track our work over a quarter and have quarterly planning meetings to discuss how we did and what we intended to do the next Quarter. And these Versions were a big part of that tracking.

Another use for them is to use them for specific projects or initiatives. For example, a Marketing team could use them to track work going towards specific Campaigns. Or an IT Team can track a specific upgrade using a Version. This is a potent tool for organization if you think about it slightly differently and not take the words at face value.

To be able to create a Project Version, a user will need Project Administrator permissions. However, my practice is to go ahead and assign this to a team lead anyways, so this is hardly a concern. If a person has this permission, they can create a Version ad-hoc in an issue, from the “Releases” sidebar, or the Project Administrator menu.  

Components

Components, like Versions, are a way to organize issues. “We already have Versions; why do we need this?” you might be asking. And well, good question!

I like to think of components as they are a way to organize on a functional level. This contrasts with Versions, which are a way to organize issues on a timeline. Versions should have a start and a stop date to them. If it is a task that goes on forever, I would argue that should have been a component, as it’s a functional part of your team’s work. 

For example, I described how a previous team I was on would use Versions to mark each Quarter. Well, we’d use components to mark work done against Confluence, Jira, Bitbucket, Bamboo, Build Machines, Installers, etc. Using both, we can dig down and filter to tasks that have to do with Confluence that need to be done this Quarter.

Like Releases, you can also access these from either the Project Sidebar or the Project Administration Menu. You will also need the Project Administrator permission to create or modify Components, but having it will let you do that from either location and ad-hoc in an Issue.  

One special function of Components is that they can help with auto-assignment. Each Component can have a “Component Lead.” If you set a Component lead, then set the default assignee for that Component to be “Component Lead,” any issue created with that Component that doesn’t manually set an Assignee will be assigned to the Component Lead. If more than one Component is set, Jira will use the first Component selected.  

Issue Collectors

There are many ways to get issues into your Project. You can create them manually, import a CSV file, use a Service Management portal, or use an email Inbox. But, did you know there’s yet another way?

If you look at your Project Administrator’s menu, you can see a tucked-away section called issue collector. To quote Jira on what it does:

An issue collector allows you to quickly gather feedback on any website in the form of Jira issues, even from users who don’t have Jira accounts.

Jira v. 8.13.1, circa 2020

To set up this feature, you need to get help from (or be) a Jira Administrator. From there, they can go in, set it up, and hand you a snippet of HTML to include in your site’s body. Just an easy way to get information quickly from your users!

So, where would you use this? Well, the obvious use case is already stated. Still, I’d also consider using this in Confluence/Bitbucket/whatever other site I managed to get bug reports or other issues from users where they are. I even put it in the corner of my Jira instance using the Announcement banner.

Project Links

Just as they say no man is an island, it’s rare to see a Jira instance stand alone. Instead, you’ll most often see an accompanying Confluence instance, and in development organizations, some sort of Source Code Management. Inside those, there will be spaces and repositories, each (hopefully) with a specific owner. So wouldn’t it be nice if you could tie a Team’s Confluence Space, Jira Project, and Repo together in one nice little bundle?

You can! You will need a Jira Administrator to help set it up. Still, it will allow you to link documents to issues more quickly, create branches in the correct repositories, and help your team navigate more smoothly between the various Applications.   

Notifications

Oh, Notification schemes. If a Project Admin is going to get themselves in trouble, it will be here. But first, let us dive into what they are and why you want to play with them.

A notification scheme maps who needs an email for the different events in a given Jira Project. Here is a list of the default events, but be aware you can add custom events in workflows, too.

• Issue created
• Issue updated
• Issue assigned
• Issue Resolved
• Issue Closed
• Issue Commented
• Issue Comment Edited
• Issue Comment Deleted
• Issue Reopened
• Issue Deleted
• Issue Moved
• Work Logged on Issue
• Work Started on Issue
• Work Stopped on Issue
• Issue Worklog Updated
• Issue Worklog Deleted
• Generic Event

Except for the “Issue Comment Deleted” event, by default, all these issues will send out an email to All Watchers, the Current Assignee, and the Reporter. However, you can create a custom scheme that includes a particular person, group, access level, etc., onto any event. 

So, why will this get people in trouble? Well, let me tell you about a particular team lead. He decided one day that he didn’t really know what was going on with his project. So his solution? He wanted an email every time anyone did anything within his project.

So, as the resident Jira Guy, I met with him and heard his concern and proposed solution. I, knowing how much actually happens in Jira, warned him against it. I gave him alternatives, proposed we scaled it back, everything I could think of. But, he would not be dissuaded. His solution was his charted course, and he was convinced it was the only way.

So, sometimes, you have to let people learn the hard way.

He lasted about a week before he came back to me, saying he wasn’t expecting to get so many emails. So we sat down for another meeting, talked through the events he cared about, and set it so he would not get as many emails.  

As you can tell, this is both an idea of how to use this feature, but also a cautionary tale. Only recently has Jira been set up to send up several notifications in a single email, and even with that, it’s still easy to flood your users with too many of these things. They are invaluable if you want people to be emailed about a particular event, but “With Great power so on and so forth.”

Did you enjoy the ride?

I just wanted to remind everyone that today Coyote Creek is hosting a special Talk with Box, QAD, and Atlassian about non-traditional uses for Jira Service Management. If it wasn’t obvious yet, I love collecting these “outside the box” uses for Jira as Ideas I can steal later if needed. So I hope you will join me for this webinar!

On another note, I announced this weekend that I will be speaking at Jiracon this coming October. There, I will be talking about why I’m sticking with Atlassian despite the rapid changes happening. I certainly hope you will join me there! Click below for more details!

As always, you can catch me on LinkedIn, Facebook, Twitter, and Instagram, where you can get the latest posts, news from the Atlassian Ecosystem, and what’s going on with The Jira Guy. You can also sign up below to get new posts email to you as soon as they publish! But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”