Atlassian Remote Summit Scheduling

Hey guys! Just a quick heads up – Tomorrow’s normal post will be delayed. This is so I can watch the Remote Summit’s keynote and be able to give you the news about what’s new in the world of JIRA, Confluence, and all the Atlassian tools.

Unfortunately the keynote starts 30 minutes before I normally release posts – there is no way I can write that and get it up here with any kind of quality. So I’ll be delaying it to later in the day to get it up here for you.

Additionally, I’ll also be doing a bonus post Thursday with information from that day’s keynote! So you’ll have to wait a bit, but you’ll be getting twice as much content this week!

Thank you all for your patience here. Don’t forget you can check out the Remote Summit yourself by signing up here: https://atlassian.swoogo.com/summit20_live_stream/submit

Until then, this is Rodney, asking “Have you updated your JIRA Issues today?”

Its all about them schemes

Last week we took a look at cleaning up your fields to help improve your system performance. So now we move on to our next Atlassian TAM suggested topic: How to standardize workflows and screens. But before we dive in…

Last week was amazing. I had a lot of engagement on this topic, and even had two more people come forward with requests for more topics to write about. I’m always up to do a reader suggested topic, so if you have something you want to see covered, let me know! It may be a few weeks before I can write on your topic (For once, it’s nice to have a backlog!), but I’ll definitely get to it. You can use the contact form on the blog’s website, or email me directly at contact@thejiraguy.com.

Anyways, lets get into it.

So, let me ask: Why would you want to standardize?

Fair question. This is going to be a lot of work, negotiation, and may come down to you telling them this is how it’s going to be. Why bother?

What’s the benefit that will make all this worthwhile? Well, the first benefit it helps teams within your organization work better together. If a person has to move from Team A to Team 1, they don’t have to relearn how to use JIRA. They’ll see the same fields and the same workflows. They’ll know how to use the tool as they’ve always have and be able to focus on getting to work that much quicker.

Secondly, It will help with reporting. With all the teams using the same workflows and fields, we have a consistent set of data across all teams with which to run reports and measure performance. While you should NEVER compare teams’ velocities to each other (as each team will value story points differently, therefore you will never get an oranges-to-oranges comparison), you can measure most other things consistently across the teams if they are all working from the same field set.

And the third, and I’d argue the most important reason to consider standardizing your schemes is your sanity. Look, there is only so much JIRA Admin to go around. If you are lucky, your organization has two or three of them to help out – but that’s usually for the largest organizations. Most small and medium businesses, it’s on you. Having standardize schemes stops you from having to play “What impact will this change have?”. You’ll know, and be able to get on with it that much faster.

But what about the exceptions?

Look. There will always be exceptions. A process or team that doesn’t adhere to normal business models. My Approvals workflow is such an example. But it’s your job to make it just that: An Exception. If you standardize your workflow, any change that is proposed by a team using the standard schemes should be measured on “How will this benefit the entire group?”. If it’s a benefit, it should be applied to the entire scheme. No breaking off a scheme to apply to a specific team. It’s all or none.

This, in and off itself, can help limit JIRA bloat. If a team has to defend why their change will benefit everyone, not just themselves, they will sometimes decide it’s not worth it.

So, where do I get started?

Honestly, I’d start with the screen schemes. And the first step is to talk with each and every one of your teams. Figure out what fields each one is using, and how they are using them. This will be time consuming – just a fair warning. But to do this successfully requires you to put in the work and really get to know your teams and how they work within JIRA.

Once you have that, sit down and compare your notes from all the teams. (You did take notes, right?) Find similarities, and try to get down to the fields you can get away with to allow as many teams to work as they already do as possible. Try to avoid fields that are used by only one team – opting instead to put that information in another field if possible, or the description. Take this time to use your test instance to make the changes. This will be both your testing and give you a way to demonstrate the change in a real way in our next step.

Now that you have your proposed standardized fields, this next step is probably the most important. Go back to each team, and present the new scheme proposal to them.

No, Seriously. Review what changes will impact their team specifically, and explain why you are making each change. Get feedback. Listen. Negotiate. Being willing to work with each team on this process is how you build buy-in, and it’s how you will make this process a success. Not everyone will be a 100% happy, and you may have to add some fields back in, but you can get them to a point where they can at least agree to the change. Again, I know this will take time, but having gone through this process myself, it is absolutely required.

So, you have con-census and buy in from your teams, and you have the changes ready to go in your test instance. You are now ready to push this to production..which in vanilla JIRA isn’t going to be fun. Without any plugins, you will need to manually recreate the new schemes in your production JIRA Instance, then assign all the appropriate projects to it. Or – you can use a tool like Botron’s Configuration Manager to copy over the new config as it exists from your test to production. Either way, I usually schedule a full change window for this during a relative down period for the instance (which invariably ends up being Saturday). No need having people try to work around you as you make these changes.

And that’s your Screen schemes standardized! When you are meeting with the teams, they may not understand why you are doing this. Stick with it – they will see the benefits eventually, and wonder why it wasn’t always like that.

But…uh…what about workflows?

Are you Forgetting something? Maybe you are,
Maybe you aren't - Are you Forgetting something? Maybe you are,
Maybe you aren't  Scumbag Brain

Yeah…workflows. I hadn’t forgotten about it – I was strategically putting it off. I promise!

My experience has been standardizing workflows is a bigger fight than screen schemes, which is why I chose to lead with that. People are willing to be flexible on fields – most people don’t use most custom fields anyways. But when you start messing with their workflows, you are messing with how they work. And yeah – that is part your job – but it’s going to be a fight. So start out with the screen schemes and build up some good will. That will make this easier.

With the Workflow schemes at least, you have the information at hand for each team. Teams are somewhat free-form in how they use fields, so you have to interview them first. But a workflow can only be used as designed. So start by looking at all the workflows for the projects you wish to standardize. Figure out the common points, and design a workflow (in your test instance!) that matches as many of them as possible.

Now that you have something designed, take it to those same teams. Explain to them what you hope to achieve, and demonstrate how the standard workflow you are proposing differs from the one that particular team is currently using. Go through the same thing with each team you did with the fields. Explain the benefits of everyone working on the same scheme. The object here is to build con-census from the ground up.

Look, I’m not going to sugarcoat it. People are going to disagree with you. Some are even going to do so passionately. Don’t make enemies of these people. If they care about how JIRA is being used THAT much, they are a person to have on your side. Figure out what their objections are, and figure out a way to address or otherwise work-around those objections. But show you are willing to work with their concerns, and they will be more willing to work with you.

Once you have all the concerns addressed and con-census built, schedule a change window and put it in place. You can do it manually, or by a plugin. Honestly, I keep harping on the plugin as an option as it eliminates some possibilities of you making a mistake. But if you are going to do it manually, at least export the workflow and re-import it into production, so you don’t have to worry about a mistake there.

And that’s it!

Look, this won’t be the easiest thing to do as a JIRA admin. People can be very passionate about how they work, and if you are seen as messing with that, they can get upset. But remember that they are upset because they do care, so if you can show that you are willing to listen and work with them, it should help.

So I know everything else in the world has been going a little crazy right now. I really hope you all survived the transition and ramping up your teams to work remotely. I’ve been stuck at home anyways while I recover from the surgery, but even before that I’ve been a remote employee for some time, so it still business as normal for me. I can write a post on tips and tricks from working from home, but it’s all likely advice you’ve heard elsewhere already, so unless requested I don’t have a plan to write on that topic. But if you are interested, let me know!

Don’t forget you can subscribe to receive new posts from this blog via email! To subscribe, just put your email in the form below this post! We also have an officially Unofficial Atlassian Discord chat. Swing in, ask questions, and see what’s going on! https://discord.gg/mXuRsVu

But until next time, this is Rodney, asking “Have you updated your JIRA issues today?”

Spring Cleaning for Custom Fields

Well, I’m back…or at least upright. Thank you all for the well wishes I’ve received. As much as I hate not posting an actual article, I really did need the week off to recover. But now it’s time to get back to it. As I’ve stated, this week’s article was going to be a reader selected topic. It seems there was some demand for each, but the clear winner was…

I’ll be tackling the other articles in the coming weeks, but lets look at Getting those custom fields under control this week.

A bit of a confession here.

First, let me say that as Admins, I think each one of us has various strengths and weaknesses. Me, for example. My obvious strength is Systems. I can tune almost any system to run smoothly. I can learn new back-end technologies with almost no lead-time and still successfully deploy.

However, my weakness as a JIRA Admin is I’ve never been able to execute a successful Cleanup. I’ve known the problem, and I’ve worked to fix it. But I’d rather be a con-census builder than a dictator when it comes to JIRA, and people LOVE their custom fields.

To manage this, I’ve always put safeguards to keep things getting worse. I re-use fields rather than create new ones, and really analyze whether new fields are needed. But on systems I’ve taken over, it’s rare I get a group to give up a field that was already existing.

That being said, if you want to learn from a real master of this topic, I’d highly recommend Rachel Wright’s JIRA Strategy Admin Workbook.

However, I’m going to give you tools to analyze the problem, see what fields aren’t being used, and give you the data to say to people “This…this is a problem we can fix.” Then I’ll show you how to go about cleaning things up. So, lets learn together!

Why does this even matter?

So, you might be asking yourself “JIRA is all about the custom fields, why should I worry about how many there are?” That, honestly, is a fair question. But the reason you should care is performance. It’s just a fact: The more custom fields your system has to parse through, the slower things like creating an issue, searching, etc will be.

Average response times per action (in milliseconds): custom fields test. Courtesy Atlassian.

Take a look at this chart above. This is from some testing Atlassian did. If we look at JQL Searching alone, at 1400 custom fields, the performance is abysmal at almost 3 seconds. However, doubling the custom field count to 2800 triples that number to nearly 9 seconds.

And yes, this is an extreme case. But users will notice a delay of half a second. You will get comments saying JIRA is slow even at that number, trust me. And it doesn’t take too terribly many custom fields to get searching to be that slow. That is why your custom field count matters.

Analysis

It is said the first step to fixing a problem is admitting you have a problem. Check. The second step it would seem is to figure out how big the problem is. Unfortunately, for this part we are going to have to go directly to the database.

For all my databases, I like to keep an administrative read-only account that will allow me to go in and query from time to time. This helps with making sure things are running properly, or diagnosing problems every now and again. Just make sure it’s read only so you don’t mess with something that aught not to be messed with.

Anyways, Atlassian has some queries that will help you figure out what fields are being used in your system. You can find all of them available here:

All the queries below I have confirmed are still working for MySQL 5.7 and JIRA 8.5.3.

Unused custom fields

select count(*), customfield.id, customfield.cfname, customfield.description
from customfield left join customfieldvalue on customfield.id = customfieldvalue.customfield
where customfieldvalue.stringvalue is null 
and customfieldvalue.numbervalue is null 
and customfieldvalue.textvalue is null
and customfieldvalue.datevalue is null
and customfield.CUSTOMFIELDTYPEKEY not like '%com.atlassian.servicedesk%'
and customfield.CUSTOMFIELDTYPEKEY not like '%com.pyxis.greenhopper%'
and customfield.CUSTOMFIELDTYPEKEY not like '%com.atlassian.bonfire%'
and customfield.CUSTOMFIELDTYPEKEY not like '%com.atlassian.jpo%'
group by customfield.id, customfield.cfname, customfield.description;

So, the first logical question is to ask is what fields are just not being used – period. These can probably be thrown out easily enough. Just a word of caution with this query: It can return fields that are being used by Apps using their own datastore. I’ve modified it to at least throw out results from JIRA Service Desk, JIRA Software, Capture, and Portfolio So make sure you are vetting this list for such false postitives. But if it’s a field you or your team has created, and it’s on this list, it might be time to have a discussion on whether it needs to be around.

Custom fields that have not been updated after date (YYYY-MM-DD)

select field.id, field.cfname from customfield field where field.cfname not in (
select item.field from changeitem item
JOIN changegroup cgroup ON item.groupid=cgroup.id
where item.fieldtype='custom' and cgroup.created > 'YYYY-MM-DD'
) and customfieldtypekey not like '%com.pyxis.greenhopper%'
and customfieldtypekey not like '%com.atlassian.servicedesk%'
and customfieldtypekey not like '%com.atlassian.bonfire%'
and customfieldtypekey not like '%com.atlassian.jpo%'

So this one returns fields that haven’t been used after a date. You’ll have to modify the query by replaying “YYYY-MM-DD” with a date you are interested in, but this one is handy for an end of year review, as it can answer “What fields have we not used this year”. If your teams haven’t touched the field in that long, you have a strong case for it’s need to go away.

Custom fields with low usage

select count(*), customfield.id, customfield.cfname, customfield.description
from customfield left join customfieldvalue on customfield.id = customfieldvalue.customfield
where customfield.CUSTOMFIELDTYPEKEY not like '%com.atlassian.servicedesk%'
and customfield.CUSTOMFIELDTYPEKEY not like '%com.pyxis.greenhopper%'
and customfield.CUSTOMFIELDTYPEKEY not like '%com.atlassian.bonfire%'
and customfield.CUSTOMFIELDTYPEKEY not like '%com.atlassian.jpo%'
and customfieldvalue.ID is not NULL
group by customfield.id having count(*) < 5
order by count(*) desc

Unlike the first query, this one will return fields that do not meet a certain threshold of usage. As written, this threshold is 5 issues, but you can adjust it by changing the number in “count(*) < 5”. As a rule, I like to keep this to one-tenth of one percent of the total number of issues in your instance.. So if you have 400,000 issues in your instance, the threshold would be 400. But that is a personal preference, you should set this wherever it makes sense for you.

So, what now?

You know have your information, and you know what fields are not being used. You can just go and delete them, right?

Well…

Not really. You should do some more digging. Who asked for that field to be added? What was their business case? Was that field just recently added? For those with a small usage, are they only being used in a specific project? If so, what is the usage within that project?

Also, use Botron Power Admin to see where all the field is being used (or not used). This might tell you who you need to talk to as well.

This should help you narrow down your candidates further. Once you do that, go back to whoever requested those fields. Take the data from your queries, and let them know that the fields aren’t being used, and are on a list to be removed. You can also include documents on how custom fields impact performance for everyone. If you are lucky, they’ll agree with the data and you can remove it. If not, start negotiating. See why they think they need a field they aren’t using. See if there is a way you can give them their ask without the field.

Custom Field optimizer (Data Center)

For those of you on Data Center, JIRA has a built-in Custom field optimizer you can use. It will go through and find fields that are not used often, or otherwise “misconfigured” (As defined by Atlassian).

As you can see, it’s alerting on a field in my instance that has a global context. This was one I specifically created to test the optimizer, so it’s Ideally, you should limit your custom fields to only be available to the projects that need it. So you can use this tool to find those with global contexts and if necessary, fix them.

Merging Fields (App Required)

So, lets say you have a duplicate field. How do you copy the information from one to another so you can delete one without losing data?

Well, as you can guess, this isn’t something that is able to be done in vanilla JIRA – so we have to turn to the Atlassian Marketplace – and specifically Adaptavist’s Scriptrunner plugin.

Now my groovy – it needs some work. But Scriptrunner has a number of built in scripts, including one to “Copy custom field values”. This does what it says on the tin. It takes the value in a source field, and places it into a destination field, overwriting what was there. For most cases, this won’t be a problem for reasons I’ll talk about later, but do keep this in mind.

To use this, you will first need to save a filter that will limit what issues it will copy the fields on. I use something along the lines of:

"Custom Field A" is not EMPTY

This will return all issues that has the custom field set. You can add another clause to weed out those that have the destination field already set, and handle combining those manually. In most cases, each of the duplicate fields would have only been used on a project or two a piece, and have no overlap, so this shouldn’t be too much of a concern, but as always do your research first and make sure that is not the case in your situation.

Now, I shouldn’t have to say this, but always test any changes you want to make before doing it in production. That’s very true here. This built-in script isn’t perfect, and you may have to pick it apart and modify it a bit to get to your use case. The only way to know if this is required is to do your testing.

That being said, I asked my colleagues at Coyote Creek about merging fields, and Neil Taylor gave me this as a solutions he’s used before. From testing it, it’s the easiest to implement and execute that I’ve found, and should handle most of your use cases.

So time to get cleaning!

So you know how to find fields that are good candidates to removal, and have an action plan to migrate the data should they have anything worth keeping in them. What are you waiting for? Get out there, start conversations, and get yourself on a better path to better JIRA Performance.

Don’t forget to subscribe to receive new posts by email. It’s the easiest way to be notified as soon as the posts go live. You can sign up with the form at the bottom of the post. And don’t forget to check out our Atlassian Discord Chat!It’s always interesting to see who has popped up there and what’s being discussed. https://discord.gg/mXuRsVu

But until next time, this is Rodney, asking “Have you updated your JIRA issues today?”

What happens when you are busy making other plans…

So this week has been an interesting one. Today’s post will be short. I know I promised you an article this week based on how you guys voted in last week’s poll, but you see…

Something came up.

After I got done with last week’s article, I went to have some testing done to find the root cause to some health problems I’ve been having. And well, we found the problem. It was bad enough that the doctor had me go to the ER.

What she found was a very large amount of fluid around my heart. As a result, I’ve unfortunately spent six days in the hospital. Because of where this fluid was, they couldn’t remove it the normal way, so I had to have surgery last Thursday, where they removed 600ml from around my heart! I don’t recommend that as recreational activity. So not fun…

It’s been almost a week now since the surgery, and I am recovering nicely. I cannot describe what it’s like to have that much fluid removed at once, but it was a definite difference I can feel. I’ve had a busy week trying to build back my strength and recover.

Which means, as much as I don’t want to disappoint you guys, I do need to be honest with you and say that I wasn’t able do a full article this week. I’m really am sorry – I was looking forward to this article too. But priorities are priorities.

I have opted to keep the poll open for another week though, so if you didn’t vote last week, you still have a chance!

However, some other news this week.

Look, at the point I was in the hospital, I had pretty much ruled out Summit this year. No way my doctors would let me travel so soon.

But that’s okay. Due to concerns about COVID-19, Atlassian has decided to cancel the in-person Summit this year and take it virtual instead.

While I had some surprises planned if I could attend, I cannot fault Atlassian for it’s overabundance of caution. To sign up for the now free virtual event, follow the link below.

So, this week appears to be the week of the unexpected. I do apologize for not having this week’s article ready, but one of my resolutions was to take care of myself, so here we are. Until next time, this is Rodney, asking “Have you updated your Jira Issues today?”

The JIRA Guy’s Summit 2020 Preview

So, Atlassian’s annual conference in the US, “Summit”, is now less than 30 days away. And at the time of writing I don’t know if I’ll be going to Summit yet. I would very much like to, but there are some final logistical hurdles to overcome first. But, I wanted to take a look ahead to it and figure out what breakout sessions I’d recommend to you, and which I’ll be going to if I can.

Now my advice is if you can, DEFINITELY go to Summit. It is an amazing learning experience each time I have gone. But much like me, it may not be possible for everyone to go every year. As I’ve stated previously, Atlassian has been very good about posting breakout sessions and keynotes to their YouTube page. I very much intend this to be running in the background while I work if I can’t go – and I’ll definitely be focusing in on the sessions I point out here today. But if I can go, I have some special plans for you readers from this blog.

So lets get into this

How Atlassian Enterprise Services are Unleashing our potential

Speaker: Christopher Heritage, Agile Leader, NextEra Energy
Time: 02 April, 2020 @ 3:00 PM
Room: Oceanside F

So this one seems like it will be a good story on how Atlassian’s Enterprise Services – that is to say their Premier Support and Technical Account Mangers (TAM’s) helped NextEra Energy scale and grow their Atlassian deployment. I’ve also had a really good experience with the Enterprise Services people (Hi guys!), and know more than a few of them personally, so I’ll be going here for more stories I can pass on to clients who are on the fence about signing up. If you are thinking “Are Atlassian Enterprise Services for me?”, maybe check out this session to hear first hand what they can do for you.

How to clean up your Atlassian suite (without losing your damn mind)

Speaker: Alex Christensen, Lead Atlassian Suite Engineer, AppDynamics
Time: 01 April, 2020 @ 3:05 PM
Room: Oceanside D

So, you get onto a new job, just to realize the JIRA Instance is a complete mess. This is a topic I am actually planning on touching here soon. I’ve had several experiences with messy JIRA Instances, and seen many more.

So, what do you do? Alex will guide us on how they went about cleaning several “messy” instances, and best practices they do to keep it clean.

How we learned to stop worrying and love weekday upgrades

Speaker: Ed Bukoski, Software Engineer, Netflix
Time: 02 April, 2020 @ 11:00 AM
Room: Oceanside C

Okay, going to admit, the title of this one gave me a mild panic attack.

Downtime is a necessary evil, and in the days when JIRA Server was the only deployment option, it was required for an uptime. But as a point of pride, I’d prefer my systems be up when people need them – which meant I’ve done A LOT of weekend upgrades.

However, with the Data Center Deployment option, you don’t have to bring the system down to upgrade it. This does open up the ability to do an upgrade during the weekday – without the system being down for your users. This is exactly what Ed intends to talk about, and the consequences there-in. Should be an interesting talk.

How to Un-F*** Jira

Speaker: Jon Kern, Agile Consultant, Adaptavist
Time: 31 March, 2020, 1:55 PM
Room: Oceanside C

Jon here speaks to something I’ve seen to often. Agile is meant about making things simple. So why do so many organizations make their JIRA usage so complicated? This is the curse with any highly configurable tool: People will see everything they can do, and feel they need to use it all. Jon will present several best practices for administering JIRA while honoring agile principles.

Personal branding for people who hate personal branding

Speaker: Megha Narayan, Head of Brand, Atlassian
Time: 02 April, 2020, 4:25 PM
Room: Mandalay Bay J

So, something I had to come to terms with during my job hunt is that I have a brand, and I haven’t been managing it to that point. This blog has made that even clearer. Megha will be speaking to just that – how defining your brand can be a very good thing for you and your teams. She also share tips from brands like Apple and Nike that you can apply to your personal brand. Sounds like a must-listen to me

Dev Teams & Dragons: From DM to PM

Speaker: Anthony Nomorosa, UX Designer, Atlassian
Time: 01 April, 2020, 11:00 AM
Room: Oceanside F

So, what does Dungeons & Dragons, the classic yet resurgent table top RPG have to do with leading a team?

A lot actually! Anthony will share how he takes lessons learned from the game and use it to foster communication, motivation, and empathy within cross-functional teams. As I’ve recently gotten back into playing myself after some 20 years, this one is a can’t miss for me.

Will you be at summit?

As I said, I will be there if I can make it. Will you be there? I hope so!

So, for the next blog post, I’m going to be doing something different. I was recently contacted by a friend of mine that works as an Atlassian TAM. Atlassians are reading my Atlassian blog – that blew my mind. But he also had several requests of topics that we can cover – and honestly, they are all too good, I can’t decide! So instead, I’ll let you decide.

I’ll let this run to Noon EDT on Sunday, 8 March, 2020 – at which point I’ll have to start writing whatever you chose to talk about!

In speaking of the blog, we hit a new high monthly viewership in February with 550 page views! I thought it would be a while before we beat last January, as it was a rare month with five posts published, but we did it in a month with only four! Lets see what March will bring.

If the numbers are to be believed, LinkedIn hasn’t been sharing the articles the past two weeks as widely as they previously had – or our numbers would have been even larger! If you want to help me change that, start a conversation within the comments of the LinkedIn Post! That is one of the key parameters their algorithm looks at when deciding to show it to new people. Thank you!

Don’t forget to subscribe to get our new blog posts directly to your email! The Email Subscription form will be at the bottom of this post. Also don’t forget to check out our Atlassian Discord Chat!It’s always interesting to see who has popped up there and what’s being discussed. https://discord.gg/mXuRsVu

But until next time, this is Rodney, asking “Have you updated your JIRA issues today?”