The Jira Guy

Project Permissions – done right

November 25, 2020November 25, 2020 Rodney N.2 Comments

Well, this is a pleasant change—no talking about all the changes and upheaval in the Atlassian space. Just a good, old-fashioned technical guide.

So, do you know the number one mistake I see when I log onto a new Jira instance that hasn’t been managed well? The first thing I’ll often see is a bombardment of Permission Schemes – each individualized to a project and with permissions assigned directly to groups. Now, don’t get me wrong; this solution is functional. It’s just not efficient. You have to expend time and effort to figure out which Permission Scheme and which group to make any change. And there is no help if you have to make massive, sweeping changes. You’ll be at that all day.

So I thought I’d spend today talking about Project permissions, what they do, and how to use Project Roles to allow individualized permissions per project while minimizing the number of Permission schemes you have to manage.

So, what is the point of all this?

That is a fair question. For some people, the defaults will work just fine. So why bother with the minutia? Well, eventually, you will run across a use case that will require a slightly different permission setup. It could be a top-secret project to which you’d like to limit viewership. Or a process you’d like to be as transparent as possible. Understanding where and how to make changes will save you a lot of time when these situations come up.

There is also a performance concern. If you have one permission scheme per project on Very Large Jira Instances, that can quickly add up. Using an excellent method to share permission schemes can become key to helping your instance perform well. That’s why I always advocate the use of Project Roles. It’s a way to map permissions to users and groups so that you can reuse the permission scheme as much as possible.

Permission Nodes

So, what do all the permissions even do? If you read through the list on its own, it’s not immediately apparent. I mean, let’s take “Edit Sprints” and “Manage Sprints.” On the surface, they both sound like they should do the same thing, right? If you haven’t guessed, they are not the same thing. So – hold on, this section is going to pack a lot of information.

The first section here is “Project Permissions,” and they manage how you can interact with a given project and its issues – if at all.

Permission Node	What it does (In English)
Administer Projects	Grants access to the Project Administration Screen
Browse Projects	Lets someone can see the project and its issues
Edit Sprints	Allows editing of the Sprint Name and Goal, but nothing else
Manage Sprints	Complete access to Create, Edit, Start/Stop, and Delete sprints
Service Desk Agent	On a Service Desk Project allows someone to interact with Customers and use the project’s JSM Features. Note: This will use up an Agent License on Jira Service Management
Start/Complete Sprints	Lets a person start or complete a Sprint
View Development Tools	Determines whether a person can see the Development integrations on issues
View Read-Only Workflow	Allows you to view a chart of the workflow on an issue

The next section we have here is the “Issue Permissions.” This section determines how users interact with the issues in a given project, including who can create issues, be assigned to them, close them out, etc.

Permission Node	What it does (In English)
Assignable User	Whether issues can be assigned to a user or not.
Assign Issues	Whether you are allowed to assign this issue to other people
Close Issues	Lets you move an issue into a final workflow state.
Create Issues	Lets you create new issues in the project.
Delete Issues	Grants the ability to delete an issue.* I’ll talk more about this shortly.
Edit Issues	Lets you modify issue fields after creation.
Link Issues	Allows you to link this issue to another issue shortly.
Modify Reporter	Lets you modify the reporter to someone else.
Move Issues	Allows you to change the issue type or move it to another project. Note: If moving to another project, you must have the “Create Issues” permissions in that project.
Resolve Issues	Allows you to set the resolution on an issue.
Schedule Issues	Grants you the ability to set a due date on an issue.
Set Issue Security	If configured, allows you to set the issue security on a given issue.
Transition Issues	Allows you to change the status on an issue.

After this, we get a smaller section detailing how users can interact with voters and watchers on issues.

Permission Node	What it does (In English)
Manage Watchers	Ability to add others as watchers on an issue
View Voters and Watchers	See who has voted on or is watching an issue

Next is the permissions related to issue Comments. This one is where I’ll usually spend a fair bit of time detailing, as comments are one of the main ways people interact with issues. For example, if you wish for comments to be a record and therefore immutable, you’d want to remove anyone’s ability to edit or delete comments – even their own.

Permission Node	What it does (In English)
Add Comments	Grants a user the ability to comment on issues within a project.
Delete All Comments	Give you the ability to delete anyone’s comments
Delete Own Comments	Allows you to delete only your comments
Edit All Comments	Lets you edit anyone’s comments
Edit Own Comments	Allows you to edit your comments.

And now we have the Attachment permissions – which, as you can guess, controls who can post files to issues. These are set up very similarly to the Comment Permissions, so the same concepts apply.

Permission Node	What it does (In English)
Create Attachments	Lets you attach files to an issue
Delete All Attachments	Grants you the ability to delete anyone’s files on an issue.
Delete Own Attachments	Gives you the ability to delete your files on an issue.

And lastly, we have the Worklog permissions. These permission nodes affect how users can interact with Work logs, one of Jira’s more obscure features. You can log work on an issue by going to an issue (where you have the appropriate permissions), Clicking “More” -> “Log work.” Here you can put how much time you’ve logged against an issue, when you did the work, and how much work is left to do. If you have already added a time-based estimate to the task, it will deduct the hours from the work log from the estimate automatically, as well.

Permission Node	What it does (In English)
Delete All Worklogs	Gives you the ability to delete anyone’s work log
Delete Own Worklog	Grants you the ability to delete your work log
Edit All Worklog	Lets you edit anyone’s work log
Edit Own Worklog	Allows you to edit your work log
Work on Issues	The ability to go to “More“->”Log work” and submit a work log

And that’s all the Project Permission nodes, which will be the boring part. I promise, if you’ve made it here, it gets better.

How to Assign Permissions

So – knowing what these permissions do is one thing. But how do you map them to users? Well, if we go to edit a Permission Scheme, this is what we get:

Here, we can see the various permission nodes we just talked about and who is currently assigned. We click the “Grant Permission” button on the screen’s upper right-hand side to add a new assignment.

Here, we are presented with a screen asking for a Permission node and who to assign it to.

Note: I have already clicked “Show More” to show the full list.

Here, you can see we can assign permissions to a whole host of people based on several criteria. We can even specify it down to a custom field on an issue. However, I do not recommend you do too much anything below “Group” unless you have a particular use case for it (such as only the reporter can close an issue.) For the most part, I recommend you assign the vast majority of permissions to Project Roles. The exception here is you also want to add your Administrative group into the permissions schemes, so your Admin team doesn’t get locked out of projects.

So, what are these Project Roles you keep going on about?

Project Roles are a way to map users and groups to a project directly. You can see your current users assigned to the Project Roles by going to your “Project Administration Screen” -> “Users and roles.” Here you can see who is assigned to your Project and what roles do they currently reside in.

This feature is the key to how you can reuse permission schemes across projects without having to grant everyone access to all your projects. If you map a permission node to a Project Role and then a User to that same Project role, users get those permissions on your Project! This also lets your Project Admins control who can access their Project – greatly simplifying your workload.

Because who is on what Project Role is a per-project setting, the User is only granted permissions for your Project. Assigning them to a Project Role will not affect anyone else – even if you are using the same Permission Scheme. This method is how you reduce the number of Permission Schemes in your instance, by setting up Permission Schemes that use Project Roles and sharing them between projects.

So how do you setup your permission schemes?

The way I see it, there are five basic “Access Levels” for a given project. Generalized, they are as follows:

Anyone can see, create, comment, and work on issues
Anyone can see, create, and comment on issues, but only the Team can work on issues
Anyone can see or create issues, but only the team can comment or work on issues.
Anyone can see issues, but only the team can create, comment, and work on issues.
Only the team can see, create, comment, and work on issues.

So, I’ll typically create these five Permission schemes, and all mapped to the appropriate Project Roles to create the desired Access Levels. Those are my five standard permission schemes.

Then, when I coach a new team on Jira, I’ll pull their manager aside, explain these five access levels, and ask where he thinks his Team lies and why. Based on their response, I’ll suggest an appropriate access level. Unless I have a good reason not to, I’ll always guide towards more visibility than less, which means most of my projects tend to be somewhere in the top 3 permissions schemes.

And that’s it for this week!

So, what is your opinion? Are you going to explore using Project Roles in your permission schemes? How would you set it up for your org? I’d love to hear your responses!

If you’ve found this or other posts useful, consider supporting me on Patreon! Not only will you be supporting my work here, but you will get content I won’t be posting here and swag you cannot get anywhere else. You can also subscribe below to get new updates directly to your inbox as soon as they publish. If you are the social media type, you can find me on Twitter, Facebook, and LinkedIn, where I share Blog news, New Posts, and my thoughts on all things Atlassian. Feel free to share and comment on those platforms to let the Almighty Algorithms know it’s content worth sharing. But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”

An Interview with Atlassian’s Harsh Jawharkar

November 18, 2020November 18, 2020 Rodney N.1 Comment

So, I watch a lot of YouTube. No joke, it has almost entirely replaced traditional media as the primary source of entertainment in my household. Why do I mention this seemingly random fact? Because occasionally, you will see a creator get some fantastic opportunity and thank their viewers for giving them enough visibility to get it. And well, it appears today is my chance to do that myself.

After I published the “So Long, Server” post, Atlassian reached out to me, thanking me for my article and asking how they could help out. At the same time, I was still getting many questions from you, my dear readers. So, why not ask for an interview and forward your questions? That’s exactly what I asked for, and I’m happy Atlassian accepted! Today I’m fortunate to meet and interview Harsh Jawharkar from Atlassian’s Enterprise and Platform marketing team, who was gracious enough to answer questions I gathered from everyone on social media! So, let’s get into it:

[TJG] Thank you for agreeing to answer my questions. I have, of course, given my thoughts around why Atlassian would choose to sunset their Server products now, but that will always be speculative at best. Can you explain directly to the readers why Atlassian is making this move, and why now was the time to do so?

[HJ] We are making this move in response to changing customer demands since the vast majority of our customers are choosing cloud offerings to power their organizations.

Because of this, we started designing for a cloud-first future years ago, so we could deliver on the promise that we will run our software better than anyone else. As we assessed our progress towards that vision and as customers demanded more from our cloud products, we realized we needed to sharpen our focus. Dividing our resources between server, Data Center, and Cloud hindered our ability to innovate faster. By simplifying our on-premises offerings and focusing our resources, we can deliver more innovation faster.

To the point of why now – change often feels difficult, and there’s rarely a perfect time for it. At Atlassian, we pride ourselves on making hard decisions that can be painful in the short-term when we are confident that it will lead to long-term, sustainable success for our customers. By making this decision now and communicating openly while offering three years of support, we are giving our customers time and clarity so they can continue to plan for their long-term success.

[TJG] Some people are worried that Atlassian wishes to become a Cloud-Only company. Therefore, these customers are reluctant to build on Data Center for fear it will eventually have an End-of-Life. What can you say to these people to calm their fears?

[HJ] We are committed to investing in Data Center for the long term, and we hope that the velocity with which we are shipping new features and functionality to Data Center – and the fact that we are launching a brand new Data Center product, Bamboo Data Center – reassures you of this commitment. Atlassian will continue to offer and invest significantly in Data Center because we understand that it is a critical offering for many of our customers with strict business requirements or regulations. We intend to deliver a world-class experience for all of our customers regardless of how they deploy our products.

Over the past year, we’ve significantly invested in our Data Center offerings, ramping up the delivery of new enterprise-grade features like support for CDN, rate limiting, advanced auditing, and more. We also recently announced that we’re including some of our most powerful Atlassian apps and new features with our Data Center subscriptions to help you meet your need for better collaboration and increased insights.

Jira Software Data Center: Advanced Roadmaps (formerly Portfolio for Jira)
Confluence Data Center: Team Calendars for Confluence, Analytics for Confluence
Jira Service Desk Data Center: Insight – Asset Management, Insight Discovery

To learn more about what’s available in Data Center or what’s coming in the future, customers can also check out our Data Center roadmap: https://www.atlassian.com/roadmap/data-center

[TJG] Apps have been in contention on Cloud since its inception. What steps is Atlassian taking to allow things like Custom App Development and deployment without involving a third-party hosting service?

[HJ] Our new cloud development platform, Forge, which is currently in beta and on track to being publicly available soon, was designed to address just this. Forge empowers developers to easily build and run enterprise-ready cloud apps that integrate with Atlassian products, leveraging the investments we’ve made to our cloud platform.

With Forge, developers can host their apps on Atlassian cloud infrastructure, which minimizes the time, cost, and effort spent on managing infrastructure, increases admin transparency and mitigates concerns about mishandling sensitive user data. Developers can build and customize new apps quickly with the Forge UI kit, a declarative language for defining user experiences. Forge also offers built-in compliance and Custom UI, giving developers complete control over the framework used while ensuring a high level of trust for scripts running in the app.

Forge also comes with an intuitive command-line interface (CLI) tool, which offers a centralized place for app management and provides automatically provisioned environments to build, test, and deploy apps. When you use Forge, you also have the option to use continuous delivery powered by Bitbucket Pipelines and Functions-as-a-Service (FaaS) to write single functions, which means less time spent writing code and a lower barrier-to-entry for anyone wanting to write apps and integrations for Atlassian products.

[TJG] There is a lot of invaluable information on Server Products both in the Atlassian Knowledge Base and the Atlassian Community. However, some of this information applies to Data Center as well. What is Atlassian’s plan for these treasure troves of knowledge and help?

[HJ] We intend to keep and continuously improve resources available in the Atlassian Knowledge Base and Atlassian Community to help our customers get the most out of our products. Any server-specific resources in the Atlassian Knowledge Base and Atlassian Community will remain available at least for the next three years. Our Support Team regularly reviews this material in an effort to keep them up-to-date, which means you can expect us to be updating documentation to match our product offerings. For example, we will make updates to make it clear to customers when a post is applicable to both Server and Data Center. Given the volume of existing content, it will take us time to get the documentation up-to-date. We hope our customers continue to rely on the Atlassian Knowledge Base and Atlassian Community as a treasure trove of knowledge and help for all of our products.

We are also updating our Atlassian University resources and training modules to ensure that any materials originally created for our server products that are applicable to Data Center are kept up to date.

[TJG] Many small companies are caught in a tough place by this announcement. Due to regulations, they cannot move to Cloud, but their size makes Data Center fiscally untenable. What is being done between now and February 2024 to add the security and certifications necessary to allow these customers to move to the Cloud without running afoul of regulations.

[HJ] First, to clarify, our cloud products have obtained industry-accepted certifications and comply with current industry standards and regulations, so you can feel confident that your company and customer data remain secure and compliant. We run our security program in compliance with a range of well-known industry standards. We appreciate that these attestations matter, as they provide independent assurance to our customers that we are on the right track. SOC2, ISO27001, ISO27018, PCI DSS, and CSA STAR are standards that we certify against at the moment. Atlassian has also completed a comprehensive GDPR compliance program, and we offer a Data Processing Addendum for customers. More details about these programs are available on our Compliance page.

Trello is our first cloud product to have received FedRAMP certification, and Jira Software Cloud and Confluence Cloud are currently under evaluation. We’re also working on Healthcare (HIPAA) and Financial Services Industry (BaFin, APRA, US) compliance for Jira Software, Jira Service Management, and Confluence Cloud. Our cloud platform and services roadmap also highlights a snapshot of the capabilities we feature today, along with a glimpse of what’s to come between now and February 2024.

[TJG] For these same customers, is there a plan to allow smaller Data Centers to accommodate these people if they cannot move to Cloud.

[HJ] We realize this is a big shift, and we’re continuously gathering feedback from our customers. You can see here some of the ways we’re already responding to this feedback, and we will continue to communicate openly with our customers. One option for smaller server customers who cannot move to Cloud is to deploy Data Center products in a non-clustered environment, so they can keep their existing infrastructure and simply change their license key. When it comes to other ways we can facilitate a smooth transition for smaller customers moving to Data Center, we’re in active listening mode and want to make sure we make well-informed decisions that work for all our customers in the long run.

[TJG] Small teams who are moving from a smaller Server Tier under maintenance to a minimum 500 user Data Center Tier will have a dramatic increase in price – even with the incentives in place. Has any thought been given to supporting these teams with a smaller Data Center Tier? If so, what would that look like?

At this time the entry point for Data Center is the 500 user license and we have no plans to add lower tiers. However, we will continue to capture input from our customers and partners in this area to make sure we have offerings that meet your needs.

[TJG] Debugging on Atlassian cloud can be… challenging. We don’t have good access to the database or logs that many of us use for investigating problems. Has there been any thought given on how you can safely open up access to help the Admins of these instances?

[HJ] Atlassian’s cloud products are architected specifically for cloud infrastructure, so they’re not simply the server code ported to Cloud. We’ve evolved the architecture substantially to run our cloud products as modern multi-tenant SaaS services, so we can bring the real benefits of Cloud to our customers. So in terms of access to the database and logs, other enterprise SaaS products are a much better point of reference than our server or Data Center deployment options.

There are three main cases where admins rely on logs and database access for debugging today: performance and uptime, security and traceability, and change management. First, performance and uptime: when customers choose Atlassian’s Cloud, they’re entrusting us to run the software as their service provider. It’s our obligation to deliver consistently fast and reliable service without putting a burden on admins. One key benefit of Cloud is we can invest in architecture improvements, monitoring, and redundancies at a far greater scale than any one customer. We’ve been able to increase the user limits on our cloud products fivefold in the last two years without compromising performance, and we have an aggressive roadmap for continued improvements. We also back up our reliability commitments with financially-backed SLAs in the Premium and Enterprise plans, but all customers receive the benefits of our reliability work, regardless of plan.

Next, security and traceability: server and Data Center customers rely on a combination of raw application logs and network activity to investigate user behavior. While it’s not feasible to provide customers direct access to this type of log in Cloud, we’ve made substantial progress improving the audit logging features of Atlassian Access to complement the existing audit logs in Jira and Confluence. The organization audit log now covers activities like user logins, changes to product access, and group membership changes across all products in an organization. We know that our most demanding customers need full traceability of all user actions. This is on our roadmap, and we’re targeting an initial release later next year.

Last, change management: the best way we can help admins avoid debugging is to help them manage change in the first place. To that end, we’ve recently rolled out two major new investments to our Premium and Enterprise customers: sandboxes and release tracks. Sandboxes are a direct replacement for developer license keys in server and Data Center. For each production instance, you get a fully-enabled second cloud instance to test config changes, explore new features, or evaluate Marketplace apps. Release tracks allows customers to opt-in to receive updates from Atlassian on slower, fixed intervals for additional predictability into what exact changes are coming to your instance and when.

[TJG] Followup: Self Learning is an important skill for every Jira Admin to have. The fact is, we have a drought of people who are skilled in the installation or upgrading Jira. To combat this, I’ve often recommended users get a the 10 user “Starter” Tier to experiment with setting up and upgrading Jira, and have even provided guides.

However, this tier is going away, even though the need is now arguably greater than ever. Is there any sort of plan to adopt a “Starter” tier for Data Center or other non-cloud sandbox for people to learn how to setup, install, run, and upgrade Jira Data Center?

We offer a 30 day trials for Data Center versions of our products (and these trials can be requested to be extended). In addition, we have many Atlassian University courses specifically designed to train admins and users on setting up and installing Data Center products, including Jira (https://training.atlassian.com/jira-catalog).
Finally, we are continuing to build out our already extensive documentation library for admins.

So, what do you think?

Unfortunately, that is all we have time for this week. I just wanted to take a moment and thank you, the readers. I’ve mentioned this before, but my expectations for this Blog were not high when I started posting regularly. The fact that so many of you continue to visit, read, and share my content still blows my mind. And now I am getting opportunities like this – well, it’s more than I ever dared hope. So, indeed, thank you for your support. All this would not be possible without you.

So a bit of community news, Coyote Creek has gone ahead and posted the second piece from the Blog, “How to Choose between Atlassian Cloud and Data Center.” If you are fast, you can still catch their webinar on the Changes to Atlassian Server and Data Center, which will take place just one hour after publishing this post. I hope to see everyone there!

https://coyotecrk.com/wp-content/uploads/2020/11/featured-image_Server-EOL_webinar_graphic.png

Remember, if you enjoyed this post, you can always subscribe with the form below to get the new posts delivered directly to your inbox. You can also find me on Twitter, Facebook, and LinkedIn, where I share the latest news and posts, and occasionally ask for help on future posts from you, the readers. But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”

Atlassian Team Tour 2020

November 11, 2020November 11, 2020 Rodney N.Leave a comment

Well, it’s been a week, but I’m glad to be back. However, we have a fair bit of news to share. To start with, I have avenged my previous ACP-200 failure and am now certified in Confluence Administration!

If that wasn’t exciting enough, it has granted me the Atlassian Certified Master status as well!

Edit from the future: And somehow, that’s not all. As I was halfway through writing this piece, I got another exciting email stating that I’ve been accepted as an Atlassian Community Leader! This grants me access to a new wealth of information about what’s happening at Atlassian, and you better believe I fully intend to take you along for the ride.

So, it’s been a busy week, but an enormously satisfying one. However, that’s not all the news we have to get through. Today (Monday, 9/Nov/20), Atlassian is holding the Keynote for their Team Tour 2020 event, and rumors are they’ve been working on something. So let’s check it out!

And we begin!

That’s us! Coyote Creek was proud to be one of the session sponsors for the Keynote!

Did he say a new product? I saw “new product.” No details yet, but New Product warning.

Atlassian’s reminder that this is one of their core values. I know some people would argue this point right now – I won’t be one of them. I’ve spoken my piece about my thoughts on their decision, and I still feel that they think of the customers.

Cannot stress this enough. Everyone’s situation right now is Unique, and you cannot have a one-size-fits-all policy and expect employees to still feel valued.

So, this section seemed to be a bit of justification of Atlassian’s Cloud platform and their recent moves regarding Server. So, nothing much new was revealed here.

However, looks like we have a few details about Enterprise Tier.

And Integrations with Atlassian Cloud products.

Cloud Marketplace is growing, but there are still plenty of Apps that haven’t or couldn’t make the jump until…

Forge is finally out of Beta! This should allow deeper integrations for Apps, which means some of those Apps that couldn’t come out with a Cloud version might now be able to. This also means if you have any Apps you’ve written yourself for your Jira instance, they now have a chance to be supported…with some additional work.

I still hate how they brought in Data Center as an afterthought. Like, “Oh yeah, if you still don’t like Cloud, we have this. But have you heard of Cloud?”

A few notes here about their Cloud Migration tools. I haven’t had a chance to use them yet, but I appreciate that they’ve made the process easier.

So…new product time?

OH…I see – “New” Product. Jira Service Desk is becoming Jira Service Management!

A few notes here.

It’s really Service Desk ++, as it’s automagically bundled with Atlassian’s recent acquisitions.
Atlassian’s shopping spree makes a bit more sense now.
Available to all tiers, including Free. Hmmmmmm…
I love “And it’s available immediately” Launch announcements.

Project Templates! YES! I’ve been wanting something like this forever! Look, I’m no HR Expert, or Legal Expert, etc. However, having a template that gets me 90% to a user’s needs would save both the customer and me so much time in back-and-forth emails and design time.

The only thing I’d add here is that maybe consider the ability to export custom templates, and have a Template Marketplace to share and rate custom template designs? That way, the best designs can bubble up to the top.

You are not locked into the template. Nice. This means I can customize it to get it to the extra 10% the user needs.

Alright, this and the next few slides were revealed at Summit this year. However, it’s a “We do this now” rather than a “We will do this.” So worth covering again.

Integrating Bitbucket Pipelines into Jira Service Management can allow you to map deployments to determine which one may be causing a service interruption.

You can then dig into the Bitbucket commits associated with that Deployment.

After that incident, you can take information recorded in the ticket and export it to Confluence for an RCA/After Action Report.

Another automation that lets you bypass approval for minor changes…

and require approval for bigger ones. I’d still love some details about how it decides what’s minor and what’s not, and if we can customize or tune that at all.

Atlassian is really trying to expand Jira to be a universal company-wide platform. Which it totally can be; I’ve seen it done!

For more details, you can view https://atlassian.com/try-itsm.

And that’s it for this week!

So, that Keynote was shorter than Summits, lasting only around 45 minutes or so in total. However, it’s definitely some exciting news. I plan to do a full breakdown of Jira Service Management soon, so look forward to that. However, that won’t be next week. Next week – I’ve got something special planned. You see…

After my post, Atlassian’s CRO, Cameron Deatsch (yes, the one from the keynote) reached out to me, thanking me for my “So Long, Server” post and offering to help me with license cost. I, of course, accepted as we covered last week, but I also asked if Atlassian could make anyone available for an interview to get their side of the story. To which, they said yes.

Next week, I’ll have Harsh Jawharkar from Atlassian’s Enterprise and Marketing Platform team on the blog to answer some questions I’ve gathered from you, the readers. I’m incredibly excited about this and look forward to sharing it with you.

In speaking of sharing, I have another bit of news from my day-job, Coyote Creek. They also liked that post, so they’ve syndicated it to their blog – with my full permission. They are also planning to syndicate both the “So where to move to?” post and the interview next week! I’m always happy to see my work shared!

Coyote Creek also plans to hold their own webinar about the recent Server EOL, hosted by Dave Theodore and Mike Faster – two men I very much respect. In fact, I consulted with Dave about the tone for the “So Long, Server” post before I wrote it. So definitely tune in to get some more information and a chance to ask some experts.

But that’s all I have for this week. It’s definitely an exciting time, and I’m so glad everyone is along for the ride. But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”

Blog update 11/4/2020

November 4, 2020November 4, 2020 Rodney N.Leave a comment

Hey Readers,

As much as I hate to do this, I’m going to take a bit of a break, which means there will be no regular blog post today.

I’m doing this for several reasons. First, as much as I try not to show it online, Atlassian’s announcement has been as stressful for me as it has no doubt been for you. I still stand by my opinion that it’s not as “doom and gloom” as some people believe, but time will bear that out. Either way, I’m feeling it too.

Second, it has been a crazy week. Remarkably, in the past week I’ve seen tropical storms, holidays, exams, achievements, and the election here in the U.S. At this point, I just need some extra time to process it all.

However, I was still prepared to write despite all that. The final straw came with my setup and experiments for my next article. Whenever I write a technical guide, I always set it up first to test and record the method. I’m fortunate that until now, this has always worked out. However, this week I got to the point where I realized I’d have to completely start over the setup, which would have left me no time to actually write my post. And I’m not going to release a half-baked filler just to keep things going.

So, here we are. I’ll be back next week with a recap and reaction to the Team Tour keynote address – which will be a similar format to the Summit Keynotes I did back in April. I also have a few surprises that I am working on for after the recap post. I can’t reveal too much yet, but I hope to have some solid answers for you soon. #ThingsAreInMotion.

I hope everyone is also taking the time to take care of themselves too. I’ll see you all next week. Until then, this is Rodney, asking, “Have you updated your Jira issues today?”

So where to move to?

October 28, 2020October 28, 2020 Rodney N.3 Comments

Well, last week was fun, don’t you say? Well, from one perspective, it was. You guys shared, commented, and drove a ton of views to the post – so much so that it got the attention of Atlassian’s top brass. Of all the emails I was expecting in all this, that one was not it. We are still ironing out the details, but exciting things are coming for the blog.

However, time does move on, and so do we. One complaint I heard last week was my numbers were off because of one reason or another. And on that note, I must disagree with you – slightly. The situation was off, not the numbers. I was looking at a pure situation where you were running no add-ons, and you were not applying discounts. And I stated in the post that it was not a realistic scenario, but it was good enough to get a basic idea of what was going on.

The reason I went with this approach in the previous was for the sake of this post. I can analyze one situation and maybe help one person. Or I can provide a method to do your analysis and help vastly more people. I knew I wanted to do this as a follow-up. It did not help with how suddenly Atlassian announced these changes, but that’s another story.

So, let us get into it. How do you know which path you should take for your situation? Is there even an option? What are your constraints: costs, functionality, performance, or regulations? Unfortunately, there are so many variables that this answer is likely to be unique to everybody who does the analysis. So without any more stalling, here we go.

Analysis

For this analysis, I’ll be going through my process on my instances for The Jira Guy. That way, you can see what this looks like in a real scenario.

Sensitive Data anyone?

So, let me save you a step here. Are you in a regulated industry? These include industries like Healthcare, education, government work, or the financial sector. And if you are, you will likely have some regulations that apply to you. These take various forms (HIPAA, FERPA, FEDRAMP, SOX), but the fundamental uptake is that you, as the admin, are ultimately responsible (legally) for safekeeping the data stored in your Jira instance.

This requirement means you need to control your data and not having it floating in the cloud somewhere. So, your answer comes out real quick. You don’t have an option; you must use Jira Data Center. I know Atlassian is working on getting certified against these various regulations, but that doesn’t change where we currently are. And this situation sucks, as Data Center is not currently available below 500 users, but here we are.

Taking Stock

So, let’s assume that you are not in a regulated industry, and therefore have a choice. The next step we need to do is figure out what we have, how many people are in those instances, and how we expect it to grow. I like to use My.atlassian.com to get a baseline.

Numbers completely made up – but these are the products I personally use

As you can see here, I’ve listed all my current server products, their current tier, current license usage, and where I expect that to be in a year. Estimating growth can be tricky, but a best-guess is sufficient here.

System Size

Next, we need to get a measure of how many resources the system is using. The principal metric I am interested in here is how much space are the attachments taking in Jira and Confluence – as these are one of the regulated features in Jira Cloud.

To get this, I like to go to the system, and as root, run the following commands:

Confluence:

du -sh /*

Jira:

du -sh /data/*

For Bitbucket, this isn’t as important to measure out.

Given the attachment pool for Jira or Confluence, we can make a few decisions right away. We can look at the attachment limits listed here and make some inferences.

Storage for Jira and Confluence

Product with Plans		Storage
Jira Core	Free	2 GB
	Standard	250 GB
Jira Software	Free	2 GB
	Standard	250 GB
	Premium	Unlimited
Jira Service Desk	Free	2 GB
	Standard	250 GB
	Premium	Unlimited
Confluence	Free	2 GB
	Standard	250 GB
	Premium	Unlimited

So for my example, I’d be good at the Standard Tier for Jira Service Desk and Software, but for Confluence, I would need to use the Premium Tier.

Of course, if the cost of a higher tier at your user count is high enough, Data Center might be a worthwhile move. But this is why we do the analysis.

Apps

So, another thing to consider in your move is what Apps you are running. Unfortunately, not all Atlassian Apps are created equal, and each one has varying compatibility. That is to say, you might not be able to run a Server App on Data Center, and likewise, you might not find that App available on Cloud.

So the first step here is, you guessed it, taking stock. Go to each system you run, and make a list of which plugins are active on that instance. If you have any disabled, now might be a good time to uninstall them outright.

While you are looking up what you are running, also put down how vital that App is for your company. Is it a Must have or a nice to have? This determination will help you make some decisions here in a moment.

Now that you have a good idea of what is running, you have a bit of a tedious task ahead. You need to go to the Atlassian Marketplace and look up each App. We want to know which Apps are available for Cloud and which ones are available for Data Center.

At some point, you will run into a situation where an App you are running is not available for either Cloud or DC (or both!). This situation is where that Priority column comes in handy. Can you live without the App? How important is it?

As you can see from my list, most of my Apps are not available for Cloud, whereas I am only missing two for Data Center, and only one is listed as a must-have. At this point, I have two options: I can try to find an alternative, or I can re-evaluate how important it is. In this case, Reactions are nice, but they won’t kill the use case.

Now comes the “fun” part.

Do you like math and research? I hope so because that’s what’s next. We need to start looking at the pricing for the various options. To do this, I’d start looking at the pricing page on each of the products.

Take special note of the Cloud pricing as, by default, they give it to you in a “per user per month” figure – making the cost seem lower than it is. To fix this, I multiply the provided number by 12 and then again by the current number of users I have. When I get done, the figures look something like this.

Discounts

These numbers are great to have, but they still aren’t a complete picture as Atlassian is offering a one-time “Loyalty Discount” if you upgrade to Data Center. These break down as follows:

Before July 1, 2021:

Jira Software and Confluence (up to 1000 users): 25% discount from then-current published list price
Jira Software and Confluence (1,001 users and above): 40% discount from then-current published list price
Jira Service Desk, Bitbucket, Crowd (all user tiers): 40% discount from then-current published list price

Before July 1, 2022:

Jira Software and Confluence (up to 1000 users): 15% discount from then-current published list price
Jira Software and Confluence (1,001 users and above): 30% discount from then-current published list price
Jira Service Desk, Bitbucket, Crowd (all user tiers): 30% discount from then-current published list price

Before July 1, 2023:

Jira Software and Confluence (up to 1000 users)): no discount
Jira Software and Confluence (1,001 users and above): 15% discount from then-current published list price
Jira Service Desk, Bitbucket, Crowd (all user tiers): 15% discount from then-current published list price

So the earlier you move, the more you save. Combine that with the fact that Data Center’s prices are going up in Feb. 2021, waiting can cost you a LOT of money if you are leaning Data Center.

So applying these Numbers, I get the final picture of:

So now I have a complete picture. I know that I’ll be saving money this year with Data Center on every item but Bitbucket, and the price difference is close enough, I can justify the increased cost.

Looking forward

However, that’s this year. Next year, the bill will come soon enough. And with the price increases, what does that look like? I decided to extend the Excel out another row to see precisely that, and here’s what I came up with, using these tables from Atlassian.

Ouch. Well, we’ve already switched to Data Center based on last year’s number, so let’s look a bit closer. Yes, Cloud Standard is cheaper than the new prices. However, Your Jira instance already has 150 GB of attachments this year, and that’s only going to keep growing. You may need the Premium tier for that next year, or you might not. But eventually, you would cross that 250 GB Limit. And at that point, Data Center looks more favorable. So you can either go through two migrations in as many years or absorb the costs if you even still qualify for Standard next year.

Intangibles

So we’ve talked about Legal Requirements, Usage, Storage, Pricing, Discounts, and Future Price Increases. Now we get to talk about Intangibles. You can’t put a hard number on these factors, but they will have sway on how you choose.

For example, if your organization is “Cloud-First,” you will be looking to put as much into the Cloud as possible. You can’t put a number on that, but this will likely cause you to choose Atlassian Cloud over, say, hosting a Data Center instance in Azure.

Then there are the factors your users demand. Do they value Jira being available no matter where they are? Or do they rather Jira perform well no matter what? Each of these considerations would lead you to choose one platform over the other and will vary wildly from company to company.

Unfortunately, I cannot help you here without knowing your specific circumstance, but I did want to get you thinking about it.

And that’s it.

I wasn’t lying when I said a lot of factors come into play. Between App availability and requirements, legal data residency requirements, pricing, growth, usage, and even the things you can’t quantify, you have a lot to consider. However, sitting down and weighing each option should lead you to the best choice for your situation.

Remember, while you save more if you choose Data Center earlier, Jira Server will not go anywhere for three years, and the situation is very much still in development. So maybe Atlassian will consider a lower DC Tier. Or perhaps Cloud will be re-written to be much faster. As an independent blogger, I cannot tell you what’s going on inside Atlassian – I have the same view you do most of the time.

So – about the blog.

Last week…Just wow, guys. You shared the blog, helped spread it, and I still have to do a double-take at the resulting numbers. Seriously, this happened today.

Four thousand in a month. So, thank you so much. You all make this worth doing each week.

Last week, I was also contacted by someone high up at Atlassian. I won’t reveal contacts, but they stated they appreciated the post and that while Atlassian knew customers would be upset, they would hope that customers would eventually understand. And Atlassian felt my post went a long way towards that.

They also noted my concerns about having access to the Tools to make blog posts and offered to help. And as of yesterday, The Jira Guy’s Atlassian tools are sponsored and paid for through Server End of Life! I had joked once that if I could get my Atlassian bill paid for, I’d consider the blog a success. Well…here we are.

And while I still celebrate this good news, I haven’t forgotten that many of you out there are still confused, upset, and worried. I want to remind you that I intend to be your partner through this. I’ve already written a guide on setting up your own Jira Data Center instance, and once I can get approval for it, I intend to write a guide on Jira’s Cloud Migration Assistant. I’ve had my worries lifted so I can help you, and I won’t lose sight of that.

So, don’t forget to go ahead and subscribe if you found this post helpful. You can find the form for that below the post. I post new content every Wednesday at Noon EST, so also follow me on Twitter, Facebook, and LinkedIn to be alerted when new posts come up. And if you can and want to help fund what I’m doing here, head on over to Patreon and subscribe. You’ll get access to exclusive content I won’t be posting here, a chance to vote on upcoming articles, and a chance to join our monthly conference calls. But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”

So Long, Server

October 21, 2020October 21, 2020 Rodney N.7 Comments

First, I should note a bit of a disclaimer: Opinions in this blog have been and always will be mine – and in no way represent the feelings of Coyote Creek Consulting or anyone other than me.

Well, the writing has been on the wall for a while – but it seems that dreaded day is here. Last Friday, Atlassian announced that they would sunset the Server products. Starting next February, Atlassian will no longer sell new Server licenses. Three years after that, they will stop all support for Server products, including bug fixes and security updates. Afterwards, your options are Jira Cloud – which will be the only option for smaller teams – and Jira Data Center.

I want to hate this decision.

On an emotional level – this is a gut-punch. I often say I try to be one of Atlassian’s biggest cheerleaders, but this week it’s been hard to be that. I started on Server because, for the longest time, that was our only deployment model. I still run a Server instance for Jira and Confluence in my home lab to support this blog. It’s how I’m able to capture a lot of the screenshots that I require for the blog posts. My licenses will come up for renewal before the price increases take effect, so I’ll be good for another year or so. After that – well, let’s hope I can get sponsorship.

However, after running the numbers, I can’t hate it entirely. In the end, it will save most customers something. A few will pay more, and a few others are left out in the cold, but most people will save money. I will add this – if you plan on moving to Data Center, it will behoove you to go ahead and buy your licenses as soon as possible rather than wait for Feb. 2021. Those price increases are sharp, just saying.

So – let’s talk about those numbers.

Source: Jira Pricing, Future Server Pricing, and Future DC Pricing

I should note a few things here. First, I am only looking at the base Jira Software product, with no add-ons. This is not completely realistic, but it’s good enough for a comparison. I do intend to have an overview of how you can do a detailed analysis of your instance to figure out if Cloud is right for you next week. But for now, this will be good enough.

For Cloud, it is using the Standard Plan. I should also note that Data Center’s license model has a lot more tiers than Server does. So even though you might be on a 10K Server license today, it doesn’t mean you will have to go up to a 10K DC License. You might be able to get away with a 5K license if you have less than 5000 users, which would save you half that cost. Hence the asterisk.

Source: Future DC Pricing. Markup calculated as New Price / Old Price * 100

However, with a few exceptions, most people will save money versus their current Server Prices, so long as they are free to choose Cloud or Data Center. I fully get that not everyone is free to choose, but I’ll get to that in a moment.

Now let’s get into it. As best I can tell, for the big three – that is Jira Software and Core Server, as well as Confluence Server – the prices are not increasing if you pay list price. If you are on a discount plan, your costs will increase, but that’s not most of us. The other Server products will see an increase, though, so it might make sense to review Atlassian’s docs for yourself.

But back to the big three, the only costs that will increase are on the $10 Starter Package – which is going away entirely next February. That means you’d have to pay the next tier up – which is a hefty jump indeed. This one saddens me the most, as this tier is invaluable for people learning to become an Atlassian System Administrator. I’m sorry, but the Cloud is no substitute in this regard, just by the nature of being what it is.

While this loss is sad, We can at least take a look at other scenarios to figure out how it will impact you moving forward.

So, About that Cloud thing you mentioned the other week.

Look, I don’t know how plainly to put it. Right now, if you are under 250 users, and Cloud is a viable option for you, you will save money on the Standard Plan over either Server or Data Center. This “break point” shifts when the new pricing goes into place such that anyone under 1000 users is now the winner.

Now, I don’t care for Atlassian’s Cloud Product because it has its problems. No use lying about it, and that’s not what you come here for. However, Atlassian is investing heavily in it, and I don’t think the problems are unsolvable. And I’ve been given some sneak previews from Atlassian – exciting features are coming soon. So yeah, between Server’s End of Life and Data Center’s lack of smaller tiers, Jira Cloud is something to look into.

However, not everyone has that luxury. This group was my first thought as I read through the announcement, and they still are. And I don’t think Atlassian is paying enough attention to them.

Simply put, specific segments cannot move to Atlassian Cloud. Here in the United States, these include teams in the Financial Sector, Healthcare, Government work, and Education. The requirement here is almost always regulatory, which means this isn’t a preference. They are required by law to host their data.

And this would be fine if Atlassian would provide lower tiers for Data Center. But as it stands, they won’t. So if a team happens to be smaller than the 500 user mark, they now have to pay for way more licenses than they need to meet regulations.

And what about Data Center?

Look – the price increases set to take place for Data Center are going to hurt. Most are around a 200% increase in price. If you choose to move to Jira Data Center, you will be paying more over what you paid for Server after February. Just that, plain and simple. If you can lock in your license before then, you will be saving a good chunk of change for the year. So my recommendation is lock in those licenses early if you are thinking about going this route.

The good news here is you don’t have to redo your architecture to take advantage of a new DC license. You can drop it into your current Jira Server instance in place of its server license, and you’ll instantly unlock the new features associated with Data Center. From there, you can take your time to build out your infrastructure to make it a true Data Center instance – or not. All depending on your needs.

Another thing to consider on Data Center is your license model is different. On Server, your license is perpetual. That means if you let it lapse, you can still run and use Jira just fine. You won’t be able to upgrade it to a new version or get Support from Atlassian, but it will still work. Honestly, I’ve heard from some companies that run their Atlassian tools like this – only getting a new Server license when they plan to do an upgrade and only doing an upgrade every few years.

However, in Data Center, that’s is not the case. If you let your Data Center license lapse, your instance locks up, and you cannot use it until you get a new one. This is because Atlassian considers its Data Center license to be a “subscription,” which you need to pay annually. Just something to think over if you haven’t looked at DC before.

Viral Marketing

So – as I mentioned last week, I can be something of a marketing nerd. And I’ve loved Atlassian’s strategy they’ve employed for years now. They’d start small in a given company. Maybe a guy used Jira at his old job, and he recommends it to his team. They adopt it, build on it, and it works for them. The next team over sees their success, adopts Jira, and it grows. Before you know it, an entire department is using it. But then Legal notices what it can do and wants in. So does HR. And Accounting. Now your full company is using Jira, and you have a large instance.

This process is honestly how I see Jira adopted most often. It’s not a top-down decision; it’s a bottom-up grassroots movement. However, will this process still work if the teams start on Jira Cloud, where the license costs are per user? I don’t know if one team manager will want to foot the bill for another team using “their” platform. It seems Atlassian might be thinking more of the top-down approach is the future. Or they have data that says this isn’t a problem. As I said, I don’t know, but I’m going to pay attention to what I hear from the ground.

Remember, you have time.

Look, this announcement feels sudden. But don’t let it spook you. Jira Server will still be here for over three years. This period gives you plenty of time to evaluate all your options and move there before Jira Server has its End-of-Life.

However, hasty and emotional decisions are rarely good ones. It’s one reason why I wanted to wait to say much publicly until I could calm down, get the emotion out of it, and figure out the real story here. Trust me when I say that my outlook on Friday was a lot more panicked than it is as I write this today.

So stop, take a breath, and relax. You’ve got this. If you are on a Server instance, it’s not the end of the world. It’s just the start of the next leg of your journey.

Questions from you

Considering I made no secret of today’s topic to everyone, I figured I’d open it up to Social Media to see if they had any questions. And of course, you guys came through. So let’s see what your concerns are?

“Did Atlassian make a good call to announce this change considering, that cloud is still very much not a mature platform yet?” – Vitalijus Šerpytis

Do I think this timing is ideal? No – not at all. Look, we are still in a massive global pandemic, the economy is in a global downturn as a result, and to have this enormous change on what most companies consider a vital resource during this time is…less than ideal.

However, I also don’t think they necessarily had a choice. In a previous article, I made note that Atlassian is a relatively small company for their outsized reach and influence. And this small company has been splitting its attention between Server, Data Center, and Cloud for a while now.

And yes, we know Cloud has been getting the lion’s share of the investment for a while now, too. It’s where all the new “cool” features are premiered. However, Atlassian Cloud does have some fundamental problems. You know it, I know it, and you better be sure Atlassian knows it. And at their current setup, they don’t have the resources to fix that.

Atlassian also sees data that says most new people to their products are starting in Cloud. This fact tells them two things: A) Their future depends on Cloud, and B) They don’t have the resources to fix Cloud and support Server and support DC.

Between Server and Data Center, Server’s been trending downwards, while DC upwards. Of course, this trend exists – people are migrating away from Server to Data Center and Cloud, so it’s going to go down, but the data still is what it is.

So given all the facts above, if you had to make the hard choice, which would you make? As I’ve stated, I think this decision does ignore some critical use cases, but I can at least understand the decision.

“How can customers trust Atlassian is going to offer DC going forward given all their actions in the last few years?” – @jonjonbling

Hmm, just asking all the hard questions. Look, I am not a part of Atlassian, so I cannot say what they are going to do with any certainty. However, Server and Data Center have a fundamental difference that makes Data Center more attractive to keep onboard: DC is a subscription license.

For Server, you pay once for your license; then, you pay a smaller “Maintenance” fee every year after for access to upgrades and Support. If you don’t plan to upgrade and don’t feel you need support, don’t pay Maintenance. You can still use your Jira instance because you’ve already brought your license.

However, with Data Center, you pay the full price every year to continue using your Jira instance. It’s a subscription, so if you don’t pay it, you don’t get to use Jira. This pricing model brings in a lot more money to the company. It might be cynical of me, but when in doubt, follow the money. Atlassian has a lot more incentive to keep Data Center alive than Server, so it will likely be around as their “On-Prem” offering.

Here’s to a better week coming up.

This week has been a long one. I don’t know what the future may hold for the Atlassian Ecosystem or this Blog, but I know that we are adaptable, so we’ll do what’s needed to move ahead. So, I’m not going anywhere, and I’ll do my best to guide you through what’s coming up.

However, you can help now me out. If you are financially able and find this Blog helpful, consider becoming a Patreon and supporting what I do here. Depending on your monthly contribution, you can get access to a Members-only discord, exclusive content that I will not be posting publically, as well as recognition on the Blog. Higher tiers can even participate in a Monthly AMA Conference Call or even a private one on one (virtual) meeting with me. Patreon is very much an experiment, but if you find it useful, please consider supporting the Blog.

What are your thoughts? Are you angry, worried, or looking forward to the changes? Is your organization planning to migrate to another platform? If so, which one? Leave a comment on Social Media with your thoughts and help the algorithms distribute the Blog. You can find me on Facebook, Twitter, and LinkedIn, where you can find new posts, community news, and interesting tidbits. You can also put your email down below to get new posts delivered directly to your inbox. But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”

Jira 8.13 – Long Term Support Version!

October 14, 2020October 14, 2020 Rodney N.Leave a comment

It is a glorious week, everyone! After nearly a year of running 8.5 as the last LTS version of Jira (formerly Enterprise Release version), last week Atlassian released version 8.13! This is likely the version that most serious customers will be running for the next year, so I thought I’d look at the new tricks and treats that Atlassian has in this release.

Wait, Long Term Support Release? What Happened to Enterprise Releases?

Yeah – it might be confusing if you don’t follow this stuff recently. Last June, Atlassian rebranded Enterprise Released into Long Term Support Released. The upshot is still the same – where possible, Atlassian will backport all bug fixes to this version for two years. That’s two years that you can make sure that your instance is safe and running without bugs – without having to worry about testing new features that may or may not break your company’s workflows. As a rule of thumb, I always go with the latest LTS release unless I have a very, VERY good reason to pick something else, like a critical feature that isn’t available yet.

So, What do we get for upgrading?

In a word, a lot. If you have been stuck on an LTS Version, things don’t hold still. There have been seven other versions of Jira released since the last LTS Release; each chalked full of new features. While I intend to go over a few of the ones I’m most excited about for Jira Software and Service Desk – there is no way that I can reasonably cover every new feature. So – I won’t. 😛

Instead, I’ll post the links here to the full changelogs for you to review yourself.

Jira Software

New User Picker (From Jira 8.12)

So, have you ever been searching for a user, and can’t tell which “John D.” is your John Steven Doe? I have – countless times. Jira finally fixed this in Jira 8.12 – giving us a User’s avatar, email, and Name in the search!

Improved email notifications about mentions (From Jira 8.11)

So – I’ve touched on this before. Jira sends a lot of emails, and Atlassian has heard this cry. Now you can start seeing the benefits of this. Jira will no longer send you an email for every mention, instead adding it to a digest that you will receive. It will also move you up in the queue to receive the digest as soon as possible – but you won’t be flooded with mentions anymore.

OAuth 2.0 Support for Incoming Mail (From Jira 8.10)

Both Google and Microsoft are planning to disable basic authentication. We don’t know when as they are coy about the timetables – but it’s coming. However, up until now, Jira only supported Basic Auth for email. Thankfully, They are ahead of the curve and putting in OAuth 2.o support.

Dates on Future Sprints (From Jira 8.8)

Sometimes you need to plan ahead with your sprints. Up until now – you could only assign dates to the current sprint. That has changed. You don’t have to fill them out, but now have fields on future sprints for dates if so you want them.

Anonymizing Users for GDPR Compliance (From Jira 8.7)

GDPR Audits as a Jira Admin is just painful. I don’t think I’m alone in thinking that. Now it’s just a little less painful. As an administrator, you can no completely anonymize a user’s record within Jira. This is a one-way operation, so if you do this by mistake, there is no recovering that user’s information, but it will honor a user’s “right to be forgotten,” which is a happy tick off the GDPR Audit.

Jira Service Desk

Jira Service Desk support on Mobile (from JSD 4.12)

This feature is still in beta, but it’s exciting. Now you can have native Jira Service Desk support on the mobile Apps for iOS and Android. To get this rolling, you will need to enable the option in Jira, but once you do all your agents and users should be able to access the new features on their mobile devices.

Multilingual customer portal and help center (From JSD 4.11)

Not everyone speaks the same language. If you run a portal used by a world-wide Enterprise, a person speaking any number of languages could be accessing your portal. Now Jira Service Desk comes with multilingual support in both the Portal and Help Center. This feature will allow your customers to access Jira Service Desk in the language they speak. You can even add custom languages or translations.

Improvements to agent queues (From JSD 4.6)

This feature has been much needed. Atlassian has taken a look at the Agent queues and improved them. For one thing, you can now sort by columns to find the most critical issues to address first. And what’s more, the sort you apply is specific to your account, which means you won’t affect how your teammates sort their issues and find what works for you.

They’ve also added keyboard shortcuts to the queue screen so you can use arrow keys to hop between different issues in your queue.

And that’s not all!

All told, if you are upgrading from the previous LTS version to this one, you will be getting some 27 new features for Jira Software and a whopping 42 in Jira Service Desk. Some of these are from Jira Core, so they are duplicated between the two. But that is a whole lot of new toys for your teams.

A new LTS version is something to celebrate. I mean, who doesn’t want new features on a platform you know you’ll be able to maintain for a bit? Back before Enterprise releases were a thing, I often felt you needed to upgrade every six months at a minimum to keep up. And then there came Premier support “blessed” versions to keep track of. Which weren’t a particular release, only a version that Atlassian’s Premier support team had tested and felt was a bit more stable than the rest. But honestly, this just felt like another thing to keep up with – you still needed to upgrade aggressively.

Having the ability to step back and not do a major upgrade as often is very much a load off of my feet. Yeah, there are still bug fixes to test and apply, but as they don’t include new features, the testing on those is much less demanding.

So what do you think? Are you planning to upgrade to the latest LTS Release? If so, what features are you looking forward to? If you enjoyed this post, help the algorithms by leaving a like and comment on social media of choice. You can find us on Twitter, Facebook, and LinkedIn, where we post new posts, news from the community, and anything I find interesting. You can also subscribe below to receive the latest posts directly to your inbox. But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”

What’s the deal with Jira Cloud?

October 7, 2020October 7, 2020 Rodney N.Leave a comment

So, a few weeks ago, I was contacted by Jira Gal Heather Rimmey. She had seen a comment I had written in reply to someone’s comment about Jira Cloud and Jira Server. It turns out she was having the same discussion with management and wondered if I had any thoughts on the differences between the two deployment models. And well, we all know I do! This week, let’s dig into the differences and discuss when one option may be preferable to the other.

As a note, I’ll be using “Jira Server” a lot during this post. Please understand it to mean Either Server or Data Center. While the two are very different deployment models and have unique feature sets, it’s an excellent grouping to keep this post from getting too confusing.

One is not better than the other.

Let’s get this over with first. I do not think a Server Deployment is better or worse than a Cloud deployment. However, I believe that they are very different creatures who both happen to bear the name “Jira.” That is to say, just because you have experience with Jira Cloud doesn’t mean you’ll transition smoothly to a team using Jira Server and visa versa.

That’s my most significant point, and one I cannot stress enough. Most groups I talk to fail to consider a certain “relearning” time that will cause overall productivity to go down after a migration. Your teams will need to learn how to do all the things they knew on the old platform. This can be offset a bit by training, but only to a point. It’s something to consider.

Control vs. Ease of Use

This concept, as I see it, is the main selling point of Jira Cloud. You don’t have to learn how to set up a server or run an upgrade. You request your site, and within moments you have a Jira instance! Congratulations.

And this is great! If you are a small team, you don’t need that overhead. However, just like everything else Jira, this is a trade-off. Atlassian is continually pushing out updates and upgrades to Jira Cloud. This model means you often get not only bug-fixes first, but the latest and greatest features that the On-Prem deployments may not receive for months or years.

But what happens when Atlassian pushes an update that breaks your processes? Like when they pulled the Cloud version of the Automation for Jira app before the built-in version was completely ready? Don’t get me wrong, I have staked my career on Atlassian’s products, and will be their biggest cheerleader as a result, but sometimes “oops” happens.

With a Server deployment, I can find these “oops” moments in a testing phase of an upgrade. I can then choose to hold off the upgrade until I find a workaround or Atlassian fixes the bug. But you don’t get that luxury in Cloud. The best you get is the ability to put off an upgrade by a few weeks – but only on their highest-tier plan.

Again, not saying this a bad thing. It’s a trade-off for getting all the new toys before the rest of us. But it’s definitely something to consider.

Site Names

This fact maybe just me, but I’ve always been fascinated by Product marketing and branding. As my wife will attest, if I find an interesting product packaging at a grocery store, I will derail the whole thing for a moment while I take a closer look. I’ve honestly purchased some products before so that I can take a closer look at its packaging. It’s kind of sad and funny at the same time.

What does this have to do with Jira Cloud? I’m getting there. Every Atlassian Cloud instance has the following URL Structure: <yoursite>.atlassian.net. What if you prefer jira.thejiraguy.com? Too bad – can’t do that with Cloud. At some companies, this isn’t a big deal. You can still have your company name somewhere in the URL, and that’s good enough.

But that’s not every company. Some companies feel having their URL there is essential for customer perception. I can’t say I wholly disagree with this idea, either. I intend to eventually do a review on a tool that allows you to put public sites (like Atlassian Cloud) on your domain, but even that is just a workaround.

However, on Server, that is the point. You set it up on your servers, so you will need to have the URL set up, too. So you can use whatever URL you have control over.

Scaling

This is a point I think Jira Cloud does a great job on. Look, no matter how robust your system is or how much care you take over your configuration, if your userbase continues to grow, you will eventually outgrow your single server instance? What then?

Well, you are looking at a migration to Jira Data Center. This process presents its own hurdles and challenges. Just like a Server to Cloud migration, not all Apps that are available for Server are also available for Data Center. You will likely have a larger instance at this point, which means you might be trying to move a large amount of data around. Not fun.

And what do you have to do to scale Jira Cloud? Either pay for more users, or on the odd occasion, pay for a higher tier. That sounds a heck of a lot easier to me.

Apps

While this will be my last topic today, it is not anywhere near the last difference between the two deployment models. I’ll be including some additional reading if you want to explore all the differences yourself.

However, I’ve already touched on this one in this article, and it’s probably one of the most annoying things about the deployment models.

Jira Server Apps are not compatible with Jira Cloud, and visa versa. What does this mean functionally? It means that if you are considering moving from one to the other, you have to sit down and look at every single App you are running and determine if they have an equivalent on the other model. And most of the time – there will be at least one or two Apps that don’t.

Then your job is to sit back down and determine if another App is available to give you the same functionality, or failing that, determining if you can live without that App. And honestly, having to find out if you can “live without” happens more often than not.

There is another effect to this incompatibility. I cannot count how many times I am searching for a plugin to solve a specific problem, and I finally find the perfect App. It’s well-reviewed and has a large install base. And the documentation is thorough and doesn’t look too involved. Then I look up and realize it’s only for a whatever deployment model I’m not on. It’s honestly enough to drive one mad sometimes!

And that’s it for this week!

Before I forget, big news from this past week! Atlassian announced that they are renaming Summit 2021 to Team 2021! I don’t think we know if this will be the same once we can meet in person again, but I’m still excited. They have also opened up submissions for Speakers for Team 2021. I’ve put in three presentations from some of my favorite posts over the past year, and hopefully, I can get selected! If you have any interesting ideas for presentations, breakout sessions, etc., why don’t you submit too! Nothing ventured, nothing gained!

However, if you’ve found this post helpful, why don’t you give it a Like? I post new articles every Wednesday, so you can sign up below to get it delivered directly to your email inbox! You can also find me on Facebook, Twitter, and LinkedIn, where I’ll post updates, news, and new posts – so be sure to follow!

Is Jira feeling slow lately?

September 30, 2020September 30, 2020 Rodney N.Leave a comment

Well, last week. Where do I begin? Maybe here:

Yesterday tied for the best day ever on the blog! I love days like this! pic.twitter.com/klgIbkuoDy
— Rodney N – The Jira Guy (@theJIRAguy) September 24, 2020

Yeah, pretty good, right? I thought so too, then Thursday happened:

And here I was thinking yesterday was amazing. Nearly 500 views in one day! That's nearly double yesterday's! pic.twitter.com/LzcwrSy69J
— Rodney N – The Jira Guy (@theJIRAguy) September 25, 2020

Just Wow. Thank you, guys! I keep finding that just when I see the ceiling for this community, you guys go and surprise me like this.

On top of the page views last week, I also had a number of you reach out to me last week for various reasons. However, one drew my attention in particular.

Well, Harsha, it’s been a while since I released a System focused post, so challenge accepted. Fair warning, though – this topic gets intense. Jira is a rather complicated system. Even if we ignore the configuration and focus on the system, there are still many places we need to check out to know what bottleneck is causing Jira to perform slowly. But too late, you’ve already asked for it, so let’s dive in.

Lag Sources

CPU

Well, this should have been obvious as the first place to look. If your CPU is overloaded, it’s going to impact performance for the end-user. It amazes me how many people skip looking at this and head directly to adding more Heap Memory to the JVM (which we’ll talk about in a moment). If you are on a Windows Server, you will likely know how to check CPU on it via the Task Manager’s Performance Tab.

This utility will also give you information on Disk Throughput, Memory usage, and Network utilization – all good indicators if you are trying to diagnose slowness in your Jira instance. However, on Linux, I prefer to use the top utility.

This tool will tell you many of the same things, but it requires some know-how to interpret. So why use top instead of something like glances or htop? Well, it’s because top is an almost universal tool on Linux systems. It is so rare that I encounter a system without it that I cannot actually remember it. So how do we interpret this data?

The first thing I usually look at is the load average. This measurement is broken down to load over the past 1 minute, 5 minutes, and 15 minutes. Ideally, this number should not get over 80% of the number of CPUs you have. Do you have 4 CPUs? That number shouldn’t be above 3.2, for example. It’s not an exact science, but it’s close enough to work as a rule of thumb.

Another place we can look at is the CPU Utilization, underlined above. These numbers are broken down into various categories, as shown below.

us: user cpu time (or) % CPU time spent in user space
sy: system cpu time (or) % CPU time spent in kernel space
ni: user nice cpu time (or) % CPU time spent on low priority processes
id: idle cpu time (or) % CPU time spent idle
wa: io wait cpu time (or) % CPU time spent in wait (on disk)
hi: hardware irq (or) % CPU time spent servicing/handling hardware interrupts
si: software irq (or) % CPU time spent servicing/handling software interrupts
st: steal time - - % CPU time in involuntary wait by virtual cpu while hypervisor is servicing another processor (or) % CPU time stolen from a virtual machine

The two we are most interested in is “us” – this will be the active Jira Processes, and “wa” – this will alert us to a slow disk problem. These measurements are broken down as a percentage of the total CPU capability of the system – so they all should add up to 100%. So if your us measurement is taking 80% or more of the total system usage, you are using too much CPU.

So, the answer is just adding CPUs, correct? The answer here is maybe. If you are on a VM, it might hurt more than help. How so? My understanding here is that the Hypervisor (that is the VM Server) will only schedule a given cycle for the VM if it has enough CPUs free for that cycle. Therefore, the more CPUs are allocated to the VM, the more the Hypervisor has to free up, and the more time between cycles on your VM. How much is the max for your Hypervisor? I cannot say, but your Hypervisor Admin should tell based on the VM Host’s CPU Utilization.

What if the wa value is high instead? This event is a sign that your disk speed may be limiting your system performance, at which point we’ll need to look at your disk speed – which we’ll discuss below.

Heap memory

So let me say – Atlassian already has an excellent video freely available on this. It’s called “Trash Talk! How to reduce Downtime by turning Garbage Collection,” and I still reference it to this day. Seriously give it a watch.

Oh – you’re still here. Well, this is awkward. I thought everyone would have gone off to watch the video. Seriously, I was at that talk at Summit 2016, and I still refer to this video as a refresher. If you are a Jira System Administrator, you oh it to yourself, your users, and your career to learn how to tune the JVM.

So what are the take-aways from the video? First, don’t try to change the GC Method or any of the GC Parameters. Atlassian sets these to settings that will work for 99.9% of cases. I usually only touch them if asked to by Atlassian support. No – what I typically tune is just these two numbers.

As a best practice, I like to set them equal, that way the JVM will reserve it’s max amount of memory on startup. This way I won’t be surprised in a day or two by an out-of-memory error (or worse yet, the system deciding to just kill the JVM process.)

The second takeaway is that it is entirely possible to cause performance problems by setting the Heap Memory too high. Doing so can cause one of two issues. In the first problem, you end up choking out legitimate system processes from Memory, slowing down the whole System by forcing it to use SWAP space. In the second, the JVM wait’s longer to do a Garbage Collection, which means that GC Cycle will is more likely to be a full GC where the System has to pause the JVM. If the JVM is paused, it is not serving Jira Pages…hence the lag.

So, how do we know what number to set it too? We have to run it for a while, then analyze the GC Logs to find that out. If we see that the JVM is doing Garbage Collections too frequently, we need to bump it up. If we see that the GC’s are pausing the JVM, we might look at bumping it down a bit. Unfortunately, there is no hard-and-fast rule that says, “If you have this many users, set it to this.”

Fileshare/Disk Speed

Now you know the CPU isn’t overloaded, and the JVM is tuned correctly, but your System is still slow. Where do you look next? Well, the file system. I alluded to this previously, but you can get a clue if your System is having some Disk Access issues by looking at the wa statistic in top. However, while that will help if it’s high, it can give a false negative.

The Good news here is that Atlassian gives us a guide on how to run a Disk Access Speed Test.

Test disk access speed for Jira server performance troubleshooting

Basically, this will have you download a jar file from Atlassian Support, and run it against the location where Jira’s Index resides. Should look something like this:

 wget https://confluence.atlassian.com/jirakb/files/54362304/54591494/3/1444177154112/support-tools.jar
java -Djava.io.tmpdir=<Jira Home Directory>/caches/indexesV1 -jar support-tools.jar

If you run this, you should get a table like the one above. I typically look to the Median and Max columns, and compare against the table Atlassian provides (copied below).

Statistic	Excellent	OK	Bad
Open	< 40,000	40,000 – 150,000	> 150,000
Read/Write	< 40,000	40,000 – 100,000	> 100,000
Close	< 20,000	20,000 – 100,000	> 100,000
Delete	< 50,000	50,000 – 300,000	> 300,000

As we can see from my results, the medians are either in the OK or Excellent Range. However, my Max times are not (Also, OUCH on the Open Max). This result was likely an outlier caused by a problem on the VM Host, but cannot be ignored outright. If this were an enterprise setup, I’d start asking the VMware Admin questions to figure out if there are any problems with the storage and if we can speed it up at all.

My result is because I am running on seven-year-old hardware disposed of by some company as end-of-life and cobbled together by someone who is still learning.

Database

So, this will be a radical idea, but sometimes Jira’s slowness isn’t caused by Jira. Sometimes it’s caused by an external system. No, seriously, how well your Database performs will have a MASSIVE impact on how well Jira performs.

Atlassian thankfully also has a tool for this situation.

Test database performance for Jira Server

Again, this will have you download a jar and run it on your Jira server.

wget https://confluence.atlassian.com/jirakb/files/54362302/54591493/2/1444177155911/atlassian-log-analysis-0.1.1.jar
java -cp PATH_TO_THE/atlassian-log-analysis-0.1.1.jar:PATH_TO_YOUR_JDBC_DRIVER_JAR \
com.atlassian.util.benchmark.JIRASQLPerformance \
YOUR_DB_USERNAME YOUR_DB_PASSWORD \
JDBC_CONNECTION_STRING JDBC_DRIVER_CLASS \
> db-perf-test.txt

You will get the YOUR_DB_USERNAME, YOUR_DB_PASSWORD, JDBC_CONNECTION_STRING, JDBC_DRIVER_CLASS settings from your Jira instance’s dbconfig.xml file. A note on this tool: you need 1000 issues in your Jira instance to run it, as I found out the hard way.

However, Atlassian does give you an example of what the output should look like.

TOTALS
----    ----    ----    ----    ----
stat    mean    median  min max
----    ----    ----    ----    ----
retrieve-issue  5,338,000   979,000 213,000 46,007,000
get-issue   174,775 93,000  62,000  11,621,000
retrieve-workflow   5,117,153   607,000 341,000 47,738,000
get-workflow    98,996  64,000  40,000  2,962,000
retrieve-custom-field-value 601,093 495,000 316,000 23,082,000
get-custom-field-value  91,246  52,000  37,000  3,453,000
----    ----    ----    ----    ----
All times are in nanoseconds.

Atlassian states they don’t have an “Excellent, Good, Bad” chart for DB Values clearly defined, but they tend to look for any values below 20ms as good, and 10 ms as Ideal. (Remember, 1ms = 1,000,000 nanoseconds).

Network

Well, it’s not the CPU, it’s not the Memory, File System, or Database. What does that leave? Well, the network can be a bottleneck. You can usually check this with a simple ping test. Does the ping take a long time to reach the Server? Then you are more likely to see issues with Jira’s speed.

Look, I get it. You might be in India, and your company’s Server is located in the United States. You are only ever going to get your pings so low. If you are on Data Center, you can use a CDN to help with some of that latency, but it will take actual time for the packets to travel around the world.

However, if you are located in the same building as your Jira Server and are still getting high pings, it might be time to talk with your Network Admins to figure out what is going on – especially if you’ve run all the test to say it’s not the Jira Server itself.

Maybe it’s just busy.

Look, I’ve done my best to ignore the Jira Configuration in all this and focus solely on the System. However, you will get to a point where it will become impractical to add more Memory or CPUs to a server. At that point, you have two real options.

For your first option, You can do the hard work and clean up your configuration. Get rid of unused workflows and permissions schemes, consolidate duplicate custom fields, and get Jira healthy in that regard. It’s not easy, and may not be politically expedient, but it is well worth it.

Your other option is to migrate to a Data Center Architecture. Look – there are only so many users a single server can handle. Data Center Edition solves this by spreading the load out to several servers, each working together to form a single Jira instance. I have several articles already on how to convert your Jira server instance into a Data Center instance. So if this sounds like you, maybe it’s time to consider an upgrade.

Well, there you go!

Look, this is an involved topic. Pinpointing your performance issue to a single cause is tough – especially when it’s a real possibility that there are several causes. But it’s well worth it to go through each of these and see how your System is doing.

This week has been a busy one. I haven’t had a chance to read as much or do research like I usually like to do. So, I only have one webinar to share with everyone this week. “Get Jira superpowers: Reporting on Projects and Calculated Fields” is a joint presentation by Deiser, Old Street Solutions, and cPrime. And it’s tomorrow, 11:00 AM Eastern time! You should check it out!

As always, if you enjoyed this post you can subscribe below to receive new blog posts directly to your inbox. You can also like, follow, and comment on social media to help your colleagues discover our content! You can find me on Twitter, Facebook, and LinkedIn with regular updates, new posts, and news about the blog. But until next time, my name is Rodney asking, “Have you updated your Jira issues today?”

Rules of Thumb

September 23, 2020September 23, 2020 Rodney N.Leave a comment

The Merriam-Webster dictionary defines a Rule of Thumb as:

What does this have to do with Jira? A fair bit, honestly. While not hard and fast rules, these concepts can help you find your teams’ best solutions. A friend of mine suggested this topic, and I loved the idea. However, I was having a problem finishing out the post, so I had to turn to the community for more ideas. And you guys delivered! As such, I’ll be putting the source (or sources) I heard of these rules from. So let’s dive in and see what we can learn here!

1) If your workflow takes more than 30 seconds to explain, it’s too complicated. – Logan Hawkes (Coyote Creek Consulting)

So, this one is relatively straight forward. The idea is that your workflow should be simple enough that you can explain it quickly to your colleagues. If your workflow sounds like “First it goes here, then it gets assigned to this person. However, if this thing is checked, then it’s assigned over here instead. After that, it goes back here for approval before going here to have some action performed, and then it’s transferred to that department for final analysis.”

Yeah, that’s not going to make the 30-second mark. I doubt that it will survive a dedicated meeting. Let us not forget that this workflow would not only be impossible to communicate; it would also be a nightmare to maintain as well.

That ultimately is what this rule of thumb is meant to protect you from. A workflow you can’t explain effectively and can’t maintain easily does no one any good.

2) If your workflow has ten or more steps, it’s too long. – Logan Hawkes (Coyote Creek) & Matt Doar (LinkedIn)

So this is another rule of thumb meant to protect you from an overly complicated workflow. The idea is simple – if your workflow has too many steps, your users will not want to use it. No, seriously, put yourself in your user’s shoes. Would you like to progress through a workflow that has twenty or thirty steps? I have better things to do.

The number is a bit arbitrary, but it’s about spot-on. More than ten and your workflow starts to look like a mess. Below nine, and it seems doable. So as far as rules of thumb go, this looks to hit the sweet spot.

3) If you have to scroll more than twice on a screen, it’s too long. – Logan Hawkes (Coyote Creek)

This one also goes into the same category. I touched on this previously with my “Jira Sucks” article a few weeks back. Having too many fields on a screen doesn’t capture any more useful data, discourages your users from using the system, and all-in-all just looks terrible. But where do you draw the line? What number is “too many” and what is “just right.”

That’s where this rule tries to help. Rather than giving a hard number, it gives you some criteria. Two scrolls will vary user to user, but it’s close enough to provide you with leeway in making your screen.

4) If you have more than 1000 issues in your backlog, it’s a history book, not a backlog. – Sean Blake (Easy Agile)

I have seen this all too often, and I’m sure you have, too. That project that collects backlog issues like they are a collector’s item, with the “Yes, we’ll do all this someday” attitude.

Basically, your backlog grooming meetings looks like this…

If this rule of thumb applies to you, it’s time you had a hard conversation about reality and priorities. It’s time you decide what you do intend to do, what are lovely ideas but not feasible, and what you need to mark as “Won’t do.”

It might also be time to look at your process and add a triage step to filter out some noise from entering your backlog. Otherwise, you’ll wind up back here in a few months anyway.

Let me make myself clear here. If you take in public submissions for bugs, feature requests, etc., you’ll find this number to be laughably small. However, this rule of thumb isn’t meant for these kinds of queues. It’s intended for your team backlog, which should never grow that long with work waiting to be done.

5) If you need something more than labels and components to divide your work, review your process. – Jesus Oros

This one would drive me crazy. You’d have that one manager who would insist that they’d need more to be able to organize their work. It’s usually more fields, but sometimes it’s also more issue types, and on rare occasions, it’s weird workflow tricks.

However, all these divisions evaporate when you look at their process. The manager has put all of these artificial walls up that doesn’t exist. And if they do, they can use Labels or Components’ existing functionality to describe and sort accurately.

Look, a complicated process helps no one and makes life more challenging. The complications may have been thought up to try to make life easier, but they rarely do. This problem is why – save for infrequent circumstances – I still recommend a relatively simple workflow and project settings for most teams. What’s there already is flexible enough to organize work for most groups while still allowing it to accommodate 99.999% of situations.

6) If you don’t plan to either require it or report on it, it doesn’t need to be a custom field. – Rodney Nissen (Coyote Creek)

This one goes under “just because you can, doesn’t mean you should.” I get it. Custom fields are nifty. They are one of the things that makes Jira unique in its niche. But you don’t always need a new custom field for everything.

Let me explain. I once had a request come in for ten new fields. They were as such:

Process Details
Shipping Address
Cost
Shipping cost
Reason Needed
Rack Assignment
Rack Position
Purpose
Shipping Date
Received Date

Okay. So, I can immediately tell that 1, 5, and 8 are things that can and should go into the Description of the issue. Upon asking some questions, I found out that 2, 4, 9, and 10 are not going to have reports run on them, and are not required for every issue, so they can also go into the Description when needed. So within a few minutes of thinking and some questions, we have already eliminated seven of the ten, which leaves us with Cost, Rack Assignment, and Rack Position.

Cost will be needed on every request here, as will the Rack Assignment and Position. Furthermore, they plan to run a report on the Rack Assignment field to see what work has been done on which rack (to identify problem children). Those three pass the test and had field made for them. Yes, the analysis will take some of your time, but your teams will thank you in the long run, as will your Jira instance.

7) If you are creating a provision to happen once a month or one out of 100 issues, you should not be making a provision for it. – Jesse Wisener (Coyote Creek)

This idea comes from the idea that you, as the Admin, only have so much time. If you are going to spend time on an automation, provision, workflow trick, etc., it should be on something used often enough to matter. But what is that cutoff point? When is something used often enough?

Well, either once a month or once in 100 issues seems to be the happy medium. That is often enough that it will make a noticeable difference in your user’s lives, but still justify the time you’ll spend on creating and maintaining it. Some people won’t like to hear this. But no one else will do the cost/benefits analysis for you, trust me on that.

8) Start as simple as possible and only add complications to alleviate pain points. – Jesse Wisener (Coyote Creek)

This one I’ve alluded to several times, but here it is in all its glory. You should have a good reason to add anything to your setup. Workflow, field, permissions scheme, anything. Essentially, you should always seek to deliver the simplest solution possible.

Why? Well, for one thing, it’s easier to understand. You won’t have to be spending meeting after meeting explaining the solution to team after team.

And another thing, whatever you make, you will also have to maintain. The simpler things are, the better chance you have of not having something break during an upgrade.

Also, it will lead to adoption. You rarely hear, “Yo, there’s this team that has this super complicated deal, maybe we should look into it.” More often than not, people will seek to adopt and use things that they see are easy and working from other teams.

So yeah, as my Engineering professors would hammer home, “Keep it simple.”

9) Value your own time as much as you value others, and visa versa. – Rodney Nissen (Coyote Creek)

I’ve had to learn this one the hard way. Some people won’t value your time if you don’t value it yourself. For example, I made the mistake of letting people at a company know that I can use the CSV importer to bulk-create issues. One project manager went a bit crazy with that, and at one point, send me a CSV sheet with only 17 issues. He valued his time so much and mine so little that he felt it wasn’t worth it for him to make that relatively small number of issues.

I had to push back a bit, and even get his manager involved (to which his manager said to him, “You’re joking, right?”). However, it would also be easy to take to the other extreme and refuse to do anything because your time is too valuable. That is not what I’m saying.

What I am saying is that it’s a balancing act. People will need your help with the Jira instance, but you can’t let them take all of your time. Just find a common-sense point where it’s reasonable for you to help without being pushed around.

And that’s it for this week!

This post is nowhere near an exhaustive list, so I can see this being a recurring segment we return to every so often. I want to thank Logan Hawkes for both the original idea and some of the first rules to include. I just loved this idea for a post that I had to do it as soon as possible. I also want to thank everyone in the community who helped out so much in this. I knew the number of Rules I wanted, and I wasn’t coming up with enough on my own.

I loved the response to the various links I posted last week, so I figured I’d keep that up for this week. First up is a webinar/ACE virtual event, “The things that should NOT go in your Jira.” Matt Doar, Toolsmith at LinkedIn, will give this presentation on Oct 2. It’s a bit early in the day for the U.S., but it should still be well worth it to listen.

The second link I thought was interesting was an article titled, “Archiving Jira issues helped this government agency comply with privacy rules and keep Jira clean.” Yeah, it’s a mouthful, but I thought the topic was interesting. It is a reasonably good look at how they set up the system to archive issues when triggered.

Don’t forget, if you’ve enjoyed this post, subscribe below to receive new posts directly to your inbox. Be sure to Like, follow, and comment on Twitter, Facebook, and LinkedIn, where I’ll post updates from the blog, news from the community, as well as the occasional plea for help on future articles! But until next time, my name is Rodney asking, “Have you updated your Jira issues today?”

So, what is the point of all this?

Permission Nodes

How to Assign Permissions

So, what are these Project Roles you keep going on about?

So how do you setup your permission schemes?

And that’s it for this week!

[TJG] Some people are worried that Atlassian wishes to become a Cloud-Only company. Therefore, these customers are reluctant to build on Data Center for fear it will eventually have an End-of-Life. What can you say to these people to calm their fears?

[TJG] Apps have been in contention on Cloud since its inception. What steps is Atlassian taking to allow things like Custom App Development and deployment without involving a third-party hosting service?

[TJG] There is a lot of invaluable information on Server Products both in the Atlassian Knowledge Base and the Atlassian Community. However, some of this information applies to Data Center as well. What is Atlassian’s plan for these treasure troves of knowledge and help?

[TJG] For these same customers, is there a plan to allow smaller Data Centers to accommodate these people if they cannot move to Cloud.

[TJG] Debugging on Atlassian cloud can be… challenging. We don’t have good access to the database or logs that many of us use for investigating problems. Has there been any thought given on how you can safely open up access to help the Admins of these instances?

So, what do you think?

And that’s it for this week!

Analysis

Sensitive Data anyone?

Taking Stock

System Size

Apps

Now comes the “fun” part.

Discounts

Looking forward

Intangibles

And that’s it.

So – about the blog.

I want to hate this decision.

So – let’s talk about those numbers.

So, About that Cloud thing you mentioned the other week.

And what about Data Center?

Viral Marketing

Remember, you have time.

Questions from you

“Did Atlassian make a good call to announce this change considering, that cloud is still very much not a mature platform yet?” – Vitalijus Šerpytis

“How can customers trust Atlassian is going to offer DC going forward given all their actions in the last few years?” – @jonjonbling

Here’s to a better week coming up.

Wait, Long Term Support Release? What Happened to Enterprise Releases?

So, What do we get for upgrading?

Jira Software

New User Picker (From Jira 8.12)

Improved email notifications about mentions (From Jira 8.11)

OAuth 2.0 Support for Incoming Mail (From Jira 8.10)

Dates on Future Sprints (From Jira 8.8)

Anonymizing Users for GDPR Compliance (From Jira 8.7)

Jira Service Desk

Jira Service Desk support on Mobile (from JSD 4.12)

Multilingual customer portal and help center (From JSD 4.11)

Improvements to agent queues (From JSD 4.6)

And that’s not all!

One is not better than the other.

Control vs. Ease of Use

Site Names

Scaling

Apps

Further Reading

And that’s it for this week!

Lag Sources

CPU

Heap memory

Fileshare/Disk Speed

Database

Network

Maybe it’s just busy.

Well, there you go!

1) If your workflow takes more than 30 seconds to explain, it’s too complicated. – Logan Hawkes (Coyote Creek Consulting)

2) If your workflow has ten or more steps, it’s too long. – Logan Hawkes (Coyote Creek) & Matt Doar (LinkedIn)

3) If you have to scroll more than twice on a screen, it’s too long. – Logan Hawkes (Coyote Creek)

4) If you have more than 1000 issues in your backlog, it’s a history book, not a backlog. – Sean Blake (Easy Agile)

5) If you need something more than labels and components to divide your work, review your process. – Jesus Oros

6) If you don’t plan to either require it or report on it, it doesn’t need to be a custom field. – Rodney Nissen (Coyote Creek)

7) If you are creating a provision to happen once a month or one out of 100 issues, you should not be making a provision for it. – Jesse Wisener (Coyote Creek)

8) Start as simple as possible and only add complications to alleviate pain points. – Jesse Wisener (Coyote Creek)

9) Value your own time as much as you value others, and visa versa. – Rodney Nissen (Coyote Creek)

And that’s it for this week!