2 min read

Jira Tips: Create From Template vs. Create From Shared Configuration

By Katie Thomas on Apr 9, 2021 11:26:00 AM

Blogpost-display-image_Create from template vs. Create from shared configuration (1)

There are a variety of ways to create projects in Jira – whether from a predefined template from Atlassian or from a shared configuration with an existing project. As Jira administrators, this is one of the first questions you'll be faced with when onboarding new teams to the instance. Let's walk through the different strategies, and why we prefer creating from shared configuration. 

Creating from a template

Creating from the Atlassian templates will create a new set of unique schemes to that project - new items in your instance that are not shared with any other project. To create from a template, simply select one of Atlassian's predefined models on the 'Create Project' page. 

The benefit of using these templates is that each of your projects are self-contained, and a model has already been put together by Atlassian. Configuration is not shared with any other projects, even if everything is exactly the same. This means that teams can adjust their workflows, screens, etc. without affecting anyone else. This can be good for teams who don't share any processes with other teams using Jira, and allows project administrators more control over their projects. 

However, for organizations that are looking to scale and/or standardize, this can be a huge headache.

Creating from shared configuration

Using a shared configuration means that you are reusing existing and established configuration items in your instance. Rather than creating new sets of schemes when a project is created, you create based on another project. For example, if you created from shared configuration, both the old and new projects will use the same workflows, screens, and field configurations. Note that they won't share any Jira Service Management specific configuration items, like request types or queues. 

Additionally, once a project shares a configuration with another project, Project administrators can no longer edit the workflows without being Jira admins, which has the added benefit of supporting the goal of standardization and scalability in addition to administrative governance.

There are pros and cons to each of the above, but ultimately, it is recommended that whenever possible, projects should be created from Shared Configuration.

While templates allow teams to have more control over their projects, it does not lend itself to standardization or maintaining a clean Jira instance. Although IT teams often request more options for teams to self-service with Jira project configuration, in the interest of scalability, allowing any user to create their own Jira projects is not a best practice. Jira projects should not be treated as "projects", spun up or spun down on a regular basis: as a best practice projects should be long-lasting and consistent. Additionally, from an administrative perspective, it can be challenging to manage the sheer number of schemes and additional items when trying to troubleshoot issues or maintain the instance.

Looking for expert help with your Jira instance? Contact us, we'd love to help!

Topics: jira atlassian blog administrator best-practices tips
3 min read

Jira Workflow Tip: Global Transitions

By Katie Thomas on Apr 5, 2021 11:47:00 AM

Blogpost-display-image_Jira Workflow Tip- Global TransitionsBuilding Jira workflows can be overwhelming. As Atlassian Platinum Solution Partners for over a decade, we at Praecipio Consulting have spent a lot of time building workflows (seriously, A LOT). 

One piece of workflow functionality that we often see either ignored or abused are global transitions. A global transition in Jira is a transition to a workflow status that is able to be triggered regardless of where the issue is in the workflow. These can be very powerful, and we use them in some capacity in almost all of our workflows. However, there are a few things that we put into place to make these transitions easier to use. 

When do I use a global transition?

While these are not appropriate in all situations, we recommend using them in situations where users should be able to move to the status from anywhere else in the workflow. The most common use cases are "On Hold" or "Withdrawn" transitions, where users should be able to place the issue there regardless of where it is in the life cycle. It is understandable that users shy away from global transitions, as without specific configuration they have the potential to be confusing to end users and open up the workflow in ways we may not want. Keep in mind that global transitions should not be overused - using direct transitions allows for processes to be enforced, while global transitions are great options when you need to remove an issue from its normal flow.

With that in mind, we recommend the following configuration on all global transitions:

How to configure a global transition

Transition Properties

Opsbar-sequence is a transition property that allows you to determine the order of all transitions in your workflow. To use it, you assign numbers to each transition, and Jira will numerically order them on the issue view. 

Global transitions generally belong at the end of the list, so we usually give them a high number (100 or  500) so no matter how robust your workflow gets, they're always at the end of the list of available transitions. 

Conditions

Workflow conditions prevent transitions from showing when certain criteria are not met. As a best practice, we always add a condition so the transition is not available from the status it's going to – e.g. if we have a "Withdraw" global transition that goes to Closed, the condition should be "Status != Closed". If this condition isn't present you'll see the global transition available when you're in the status it's going to. 

Post Functions

One of the biggest issues that we see with global transitions is around resolution. Jira resolutions are an extremely valuable tool, and if you don't configure your global transitions correctly, they can affect your data integrity. So, 

If the global transition is moving into a "Done" status (e.g. Closed or Withdrawn), add

  1. A post function that automatically sets the Resolution, OR
  2. A transition screen with resolution that prompts users to enter a resolution before the transition

If the global transition is NOT moving into a "Done" status, add

  1. A post function that clears resolution

With the above configuration, your workflows will be more user friendly while also ensuring that your Jira data stays clean. 

Still need more help with your workflows? Praecipio Consulting is an Atlassian Training Partner with a robust catalog of training, including Workflow help!

Topics: jira blog tips training workflows configuration atlassian-solution-partner
3 min read

Tracking CSAT through Jira Service Management

By Suze Treacy on Apr 1, 2021 5:03:00 PM

Blogpost-display-image_How Jira Service Desk helps track CSATCustomer Satisfaction, or CSAT, is a customer experience metric measuring satisfaction with a product, service or support interaction. The metric is captured through a short simple survey to enable the customer to provide their feedback.

CSAT in Jira Service Management

Did you know that your customer feedback is collected by default within Jira Service Management Projects? This means that when an issue is resolved, the customer receives an email requesting their feedback through a simple question such as "How satisfied were you with our service?". That simple question is editable, and can be defined by your project admin.

Remember, if you're utilizing next-gen projects, site administrator access is required to edit your CSAT survey question

There's a handy Satisfaction report built into Jira Service Management, visible to project administrators and agents. This report displays average customer satisfaction scores, as well as individual scores and comments for the team. You can toggle the report anywhere from the past 48 hours, all the way up to the past year by month!

jira-service-desk-satisfaction-report

It's also possible to configure your own custom report to track satisfaction trends. For example, you may want to see satisfaction by assignee, satisfaction by service request, or even a trend graph to track satisfaction changes over time.

The Pros of CSAT

CSAT, a very popular methodology, offers a quick and easy way to entice customers to give feedback. This then provides a clear metric for you to understand customer expectations, and work to exceed them. With CSAT enabled, your customers will receive a survey every time their request is resolved. This enables you to track customer satisfaction at different stages of their journey with your team, making bottlenecks and areas for improvement clear, with very little effort on your part.

CSAT also offers a fast way to compare yourself to your peers. According to the American Customer Satisfaction Index (ACSI), the average CSAT score across the nation is 76.5% - that's just over 3/4 of your customers reporting a satisfying experience. This figure differs by industry - you may not be too surprised to hear that, in 2019, Internet Service Providers and Subscription Television Services reported low CSAT benchmarks of 62%, while Breweries reported a much more favorable CSAT benchmark of 85%. But remember, while it is useful to be able to compare yourself to your competition, the true value from CSAT comes when you analyze and utilize feedback to drive continuous improvement and better your own customer experience.

Considerations of CSAT

While CSAT is a useful metric to track, there are a few considerations to take into account. The customer who takes the time to fill out their satisfaction is likely one who is happy with the service they received. Customers who are unhappy, or just moderately satisfied, are less likely to complete the survey, which can skew the data. CSAT has also been found to be a poor measure of loyalty - although poor CSAT scores can predict attrition, a high CSAT score has not been found to be a reliable predictor of repeat business. Cultural differences should also be taken into account - different standards and expectations will affect the score that customers are driven to pick, which, in part, can make it difficult to understand true customer satisfaction.

So, CSAT isn't a unicorn which can address all customer concerns with support. However, it does offer a valuable insight; one which should be paired with other tools to track and measure customer satisfaction. At Praecipio Consulting, we can help you make the most out of the benefits of collecting CSAT in Jira Service Management, and use those results along with other anecdotal evidence such as customer comments, number of tickets raised, cadence call discussions, and repeat business, to drive change, improve your customer offerings, and ultimately, reap the rewards!

Topics: jira blog tracking reporting customer-experience jira-service-management
3 min read

Getting the Most From Your Jira Service Management Automations

By Jerry Bolden on Mar 29, 2021 2:45:22 PM

Blogpost-display-image_Getting the most from your JSD automationsHow many times is the number of clicks, fields or screens having to be navigated through used as a reason that work efficiency is low?  It is a main way to discuss lack of efficiency by users of any system.  Well, Jira Service Management has automation built in for just these type of issues. And when leveraged properly, Jira Service Management automation can help drive closing out issues for users as well as ensuring customers feel engaged and informed.  

While time is a focus of most people, as it is the one thing that never stops: being able to use it effectively on things that NEED your attention is key.  Yet, the first hurdle most people have is identifying what actions do not need to be performed by someone.  Automations are things that can be based on inputs by a person, and therefore are always going to be selected the same. For example, filling in a customer based on name or filling out a number field based on selection of priority.  Once these are identified and agreed upon, you can then start to figure out the next phase: how to build the workflow around these to aid in the automation. 

One of the keys to automation is how the workflows are set up in Jira Service Management.  The workflow, when configured with either the correct transition or status or combination thereof, can facilitate the automation. Having a workflow set up to allow for automation based on a specific entry into a status or trigger of transition will helps both agents and administrators of Jira Service Management manage their work more easily.  On the administrative side, the proper set-up will allow for focused automation(s) and ensure they are easy to link without writing out complicated if-this-then-that statements.  On the Agent side of the house, the simple automation UI makes it easier for them to understand their triggers. The Agent can then move on to another issue until the need for follow-up arises. For example, transitioning a request to Pending Customer may pause the SLA, but automating the transition back to In Progress based on a customer comment alerts the Agent they've received their feedback. 

At this point you may be wondering what are some of the items that can be automated in Jira Service Management to ensure efficient flow of information.  Here is a list of some of the ways to use automation for communication:

  • Customer alerts for approval
  • Alerts for review of information
  • Alert them to closure of ticket
  • Alert to lack of response

The first part of the communication is understanding what YOUR customers will need from your team to understand what is happening with their issue.  For the most part, customers want to be appraised of receipt and communication of progress consistently.  With this mindset and communication to customers, you will inevitably save time by eliminating constant customer inquiry on what is going on with their tickets or the "do you need anything from us?" question.  While this can be a bit overwhelming at first, at Praecipio Consulting, this is one fo the many items outlined in our Accelerator for Jira Service Management implementation.  We have gathered best practices from many different implementations to put together a "starter kit" on automated communications. 

The other side of the automation for Jira Service Management is automating information based on user inputs.  By filling in specific fields based on user input or spinning up linked tickets to connect to the current issue, the automation inside of Jira Service Management for tasks that, while not hard, can become tedious, is where the Agents and Customers see the benefit.  Remember, the users main complaint centers on the amount of time they take to get the issue closed and move on to another one.  So while remembering that fields can be adjusted is a good thing, spinning up another issue that is linked is even quicker, thus eliminating the time to move information and instead having it done automatically by selecting the correct workflow transition.  

Overall, the key to getting the most out of the automation in Jira Service Management is first figuring out where you can save time for the users of the system.  Second, determine how to communicate to your customers in an effective manner that can be automated, but also ensuring your customers' satisfaction.  This should be centered on letting them know what is happening with their ticket and drawing them back in to the solution when needed.  As always, anything to remove steps (clicks) from the user is going to not only get more out of Jira Service Management, but also drive a higher usage of the system, correctly, back into your organization. 

We are experts in Jira Service Management, and would love to help you make the most out of this powerful tool.  If you're curious to see if Jira Service Management is a good fit for your organization, drop us a line and one of our experts will get in touch with you.

Topics: jira blog automation workflows jira-service-management
3 min read

Three Things No One Tells You About Custom Fields in Jira

By Mary Roper on Mar 4, 2021 12:19:10 PM

Blogpost-display-image_Three Things No One Tells You About Custom FieldsCustom fields can be an over-looked configuration point in Jira, and it's easy to see why: they're easy to create, modify, and make available for your users. Although Jira ships with several system fields, it's inevitable that teams using Jira will reach a point where they require additional fields to input specific information into their issues. But in order to maintain Jira's performance as well as instance hygiene, it's important that Administrators take great care when it comes to custom field creation. That's why today we're sharing with you a few custom field insights we've gleaned over the years. Read on to learn three things no one tells you about custom fields. 

1. Technically, there is no limit to the number of custom fields you can have. BUT...

Custom fields do impact system performance in Jira. Below are some recent results breaking down each configuration item's impact on Jira. Here, we can see that custom fields have an impact on the speed of running a large instance. Your teams may feel this impact in the load time of issue screens. As an admin, one indication can be having a long page of custom fields to scroll through. Additionally, this is often accompanied by longer than usual load time for the custom field Administration page. 

Response Times for Jira Data Sets

To combat this, Jira Administrators should partner with the requestor and other impacted users to determine some guidelines for creating custom fields. For instance, requiring the requestor to submit an example of how they plan to report on the custom field or having the Administrator ensure the custom field can be used in the majority of projects (>=80%). Execution is crucial here: once the guidelines are aligned with management and stakeholders, it's crucial they are followed to prevent your custom field list from unnecessarily growing.

2. There are native alternatives to custom fields.

There are a few usual suspects to look for when reviewing custom fields. Duplicate custom fields ("Additional Comments" as a supplement to the "Comments" system field), variations of custom fields ("Vendor" vs "Vendors"), and department specific custom fields ("Company ABC" vs "Vendor") are a few custom fields that can needlessly drive up your custom field count. To prevent this from happening, Admins can offer their business partners alternative suggestions to creating a custom field by looking at the following:

  1. Utilize an existing custom field that may be more general, but is fit for the purpose to get the most out of what is already in place.
  2. Rather than implementing a custom field, Labels or Components can be used to help organize issues and categorize them for future reporting.
  3. Apply a custom field context to help maximize the potential for picker, select, checkbox, and radio button custom field types. Adding field context enables Administrators to pair different custom field select options or their default values to specific projects or issue types within the same project.

3. You can proactively manage custom fields.

Rather than waiting for custom fields to pile on and create a lag on the instance speed time, proactively scheduling time to scrub your instance for stale custom fields will help Administrators keep on top of their custom field list. This can be a visual check to understand what fields aren't associated to a screen- those are good candidates for removal- or if there are similarly named fields- those can be good candidates for consolidation. More information from Atlassian on how to identify and clean up these fields can be found here.

Ultimately, a well-maintained Jira instance includes a good understanding of custom fields and their overall impact on the system. As your instance grows overtime, the guidelines around custom field development will become all the more important. Bringing these tips to life will help your instance run at top speeds for your users. 

Need help making the best out of your Jira instance? Our experts know Jira inside-out: contact us and we'll get in touch!

Topics: jira blog best-practices optimization standardize configuration bespoke health-check
2 min read

Jira Administration: Sys Admin vs Jira Admin vs Project Admin

By Luis Machado on Mar 2, 2021 7:35:43 AM

Blogpost-display-image_Jira Administration- Sys Admin vs. Jira Admin vs. Project Admin2When thinking about Jira administration, or really administration of any software, project, or endeavor, the old idiom “too many cooks in the kitchen” often comes to mind. There’s a fine line between empowering your user base and setting the stage for mass hysteria and confusion within your instance. Fortunately Jira offers some out-of-the-box options to help with setting up boundaries for those users who need more control over the instance but keep them from wreaking too much havoc.

AdminsWe’ll start with the bottom, Project Admins. There was a time in ancient Atlasssian historical records when those who were managing projects almost had to be System Admins as well. This was because the permissions needed to make necessary regular changes to the projects these individuals were maintaining required as such. Atlasssian has been improving upon this incrementally as of Jira 7. Since that update it is possible for Project Admins to add Components and Versions to their projects and even as of 7.3, expanded with 7.4, make adjustments to the workflow among other things. So if you’re evaluating your System Admin group and discover that many of the individuals are really only responsible for maintaining specific projects it would behoove you to re-assign those you can to the Project Admin role within the projects they are responsible and get them out of your kitchen.

The next level of administration is the Jira Administrator. Now this is where things can maybe become a bit confusing because the powers granted to that of the Jira Administrator are very similar to that of the System Administrator, but there is a very key distinction which we’ll explore. Those within the Jira Administrators group are not able to make changes related to the server environment or network. This would prevent them from making changes to things such as configuring mail server settings, export/import data to and from XML, configure user directories, as well as many more functions related to the system as a whole. Where this could be useful is delegating out some of the more regular tasks such as creating new projects, creating users, etc. This gives larger organizations a way to separate out the tasks without increasing the risk of potential hazardous changes to the application.

After having covered the last two, the final role should be somewhat obvious. The System Administrator permission is for the Grand Poobah of the Royal Order of Buffalos. This role allows unlimited access to all aspects of the Jira instance. It is recommended that only 1 - 3 people maintain this permission as needed. Again, the idea is to ensure that there is concise and regulated changes being made to the instance as well as accountability. With great power comes great responsibility. When in doubt, opt for the lesser of two evils when granting administrative permissions. You can always bump them up If it’s not serving your needs. Again, the goal is to empower your user base, not have them overpower you.

For question on admins, or anything else Jira, contact us, and one of our Jira experts will get in touch.

Topics: jira atlassian blog administrator
4 min read

How to Handle Delete Permissions in Jira

By Courtney Pool on Feb 16, 2021 11:47:00 AM

Blogpost-display-image_Why you should restrict who can delete issues in JiraPermissions are one of the most important things to “get right” in Jira. Sure, having the right fields, screens, and workflows are all vital pieces of the puzzle as well, but they can easily be tweaked along the way. While permissions can also be updated as needed, a user who can’t see or edit the issues they need may have their work completely blocked in the meantime.

And then there is the group of permissions so important, so crucial, so absolutely imperative to get right that they earned a blog dedicated solely to them: the delete permissions.

“Well, of course,” you may be thinking, “everybody knows that.” But even if it may seem like common sense to you, it can easily slip through the cracks — it’s happened to others before, and let me tell you, it doesn’t always end well.

You see, delete permissions are so incredibly critical for one reason:

There is no recycling bin in out-of-the-box Jira.

This means that if something is deleted, whether through intent, accident, or malice, it’s gone. Poof. And while the loss of one item may be easy to recover from, the loss of tens, hundreds, or even thousands? Even I can feel the sweat dripping down your spine now.

So, to summarize: Delete permissions? Very important.

Types of Delete Permissions

Amongst these permissions are four groups:

  • Delete Worklogs
  • Delete Comments
  • Delete Attachments
  • Delete Issues

And two types:

  • Delete Own
  • Delete All

Delete Own Permissions

The Delete Own permissions, as the name implies, will allow a user to delete content tied to their specific user account. These permission types exist for the majority of the above-mentioned groups, with the exception of Issues.

Delete Own Worklogs applies to any time that's been tracked to an issue, whether through Jira's native feature or through an app like Tempo Timesheets. As such, it is a fairly innocuous permission and can be assigned to any user with access to a project, unless you have very strict requirements otherwise. It will likely primarily be used for clean-up, and the ripples it can cause are fairly limited.

Delete Own Comments is also often used for clean-up, and again, its area of effect is a bit smaller. However, just because a comment is deleted doesn’t mean that people haven’t already seen it, or even acted upon it. It may be better to instead point users in the direction of comment editing, or have them enter new comments entirely, even if it’s just to say, “Disregard the last.”

Delete Own Attachments is another permission that can be used for tidying. This might be useful were someone to, say, accidentally upload an adorable picture of their dog rather than the spreadsheet they were looking for. It's fairly low impact as well and can likely be given out to any users within your project, especially if you're following the Backup Rule of 3 or similar internally.

Delete All Permissions

Each of the Delete Own permissions has a Delete All counterpart. Delete Issues exists here as well, though the naming convention differs from the other four. Delete All permissions give a user access to delete items associated with any user account. As such, we generally recommend these permissions are limited to only certain groups, such as Project or System Admins.

Delete All Worklogs, Delete All Comments, and Delete All Attachments can each only be performed in a single issue at a time. This barrier helps to protect against mass deletion, but in the interest of data integrity, you’ll still want to restrict who is allowed to perform these actions.

And as for Delete Issues? This will also give a user the ability to delete from within a single issue, but unlike the three mentioned above, this permission gives a user access to Bulk Change as well, which allows actions to be taken across multiple issues at once. As such, ask yourself if you even need to grant this permission at all. Sure, there could feasibly be a time when you need to mass delete issues, but it’s likely to occur so rarely that, should those stars align, the permission can be assigned when needed to system admins and then removed as soon as the job is done. This extra step will save you from being the organization that just lost a year’s worth of tickets.

If something is deleted in Jira, it’s gone forever. This can be a nightmare for many, but especially those in organizations with heavy audit requirements. Rather than leaving yourself open to a very unpleasant surprise, do your team a favor and review your permissions now.

Stop worrying about Jira and make full use of its powerful features!  We can help you implement and optimize your Jira instance, contact us, and one of our experts will be in touch shortly.

Topics: jira atlassian blog best-practices tips configuration verify bespoke
3 min read

Individuals and Interactions Over Tools Doesn't Mean No Tools

By Morgan Folsom on Feb 1, 2021 11:00:00 AM

"Individuals and interactions over processes and tools"

It's an important line from the Agile Manifesto – one that establishes that the focus when trying to work in an Agile way is the people. However, we often see this used as a justification to provide inadequate tools to teams. In a well-run Agile organization, you shouldn't have to think about the tools - they should support the work that the team needs to do without getting in the way. Organizations often make the mistake of implementing tools to make teams work in an Agile way. However, tools are in and of themselves not enough - the people and processes behind them are what makes a business go.

However, this doesn’t mean we should ignore the tools we use, opting for whatever’s cheapest, easiest to setup, what we’ve always used, or something that’s “good enough.” Rather, we should take the exact opposite approach and select our tools purposefully, deliberately identifying the tools which best empower employees and promote processes. Because of this, there are two properties of utmost importance when considering a new tool: the tool should allow our team to run with the process that best meets our team’s needs, and the tool should help our team members work better together.

To fit the first of these criteria, the tool should be customizable in a way that allows your team to use your own process. Much of enterprise software today shoehorns teams into predefined configurations and settings which the tool manufacturer thinks are best. This leads to frustration, difficulty in using the tool, and potentially costly transitions to new software. In our experience, every team is at least a little bit different, and even two teams that want to implement the same fundamental process will find they have a few differences they would like reflected in the process. Because those differences tend to arise from the uniqueness of your team, they are important to capture in the tool in order to give your team the tools that best meet your needs.

Further, a good tool will promote communication and collaboration between teammates, inside or outside of the tool. Information tends to get lost when team members do their work in one system but communicate that work in another. For this reason, an ideal product will allow for conversations to take place within the product, ideally directly on the work item those conversations are referring to. Historical conversations should be preserved to allow for a look back on what decisions were made and why, and the tool should have options for how users are notified of important communications. Further down the collaboration path, handoffs should be made simple if not automatic, and any approvals should be doable within the tool. Finally, high-level or detailed status reports should be visible and accessible by any team member who needs or wants to see them.

These two crucial properties are two of the reasons we like Jira. Atlassian’s strategy for a long time has been to develop applications to meet the 80% of needs that are shared by most teams, such as collaboration features, malleable processes, and easy visibility of work, while allowing the remaining 20% of needed functionality to be determined by individual teams and sourced in the Marketplace. The result is a product which delivers good performance out of the box, but can be optimized to meet the needs of any team.

Consider the role that Jira plays in Agile. A large portion of the functionality is built in: Kanban and scrum boards, backlogs, issue types, workflows, and sprint reports. However, the software is customizable to the point that it works equally well for teams that have a quick, simple process with a few issue types and teams which have a complicated process with several rules, handoffs, and types of work. It doesn’t matter to Jira whether your version of Agile requires multiple manager sign-offs before it’s done or if your team lives on the edge, skips QA altogether, and goes straight to production. The point is that the software fits your process, not the other way around. Regardless of process, there are several mechanisms for the team to stay in touch along the way. Every issue can be commented on and allows for @-mentions to draw attention quickly. Email notifications are sent out at times decided by the team, not at arbitrarily defined times decided by the tool’s developers. Progress is simple to see on a board, and every user has access to generate reports or build dashboards to collect information relevant to them, reducing the need for repetitive status reports.

Most organizations will purchase a tool, kick it around for a few years, then junk it because it “doesn’t work right” or “doesn’t make sense for us.” Don’t let this happen to your organization. Pick your tools with care and optimize them for your team. And if you need help, talk with the experts, and get great advice!

Topics: jira tools atlassian-products agile
2 min read

Should my Jira Service Management instance be separate from Jira Software?

By Morgan Folsom on Jan 29, 2021 2:04:24 PM

Blogpost-display-image_Should my Jira Service Desk instance be separate from Jira Software-As companies grow either organically or inorganically, many are faced with the decision of whether they should consolidate or keep their Jira instances separate. Today I'm going to address one specific flavor of this conundrum that I am often asked about, specifically with regards to separate instances of Jira Software and Jira Service Management. Some organizations choose to have separate instances for Jira Service Management and Jira Software, but I am here to tell you that is probably not necessary!

Although Jira Software and Jira Service Management are different products, there is no need to keep them separate. The most efficient companies use both in a single instance, so that teams can collaborate much more easily. As organizations adopt DevOps or start to think about it, one of the first things that is looked at is how IT interacts with the development organization. If these two groups are working in separate Jira instances, collaboration and clear understanding of ownership and handoffs is much more difficult. For example, It is much easier to link an incident that was submitted to the service desk to an associated bug if all of those tickets live in the same instance. While you can link to tickets in other instances, that requires users be licensed in both and have a clear understanding of where the work lives. Working in a single instance removes the need for potential duplicate licenses and ensures teams can communicate clearly. 

Occasionally teams use separate instances due to security considerations. However, in almost all situations your security concerns can be addressed by project permissions, application access, and issue security. There are few cases that Jira's native security features won't account for. 

Finally, let's look at this from a user experience perspective. One of the most prominent complaints that we see as organizations undertake their digital transformations are that users have to keep track of too many tools, a pain that I've felt in my career as well. Trying to remember where to log in for a specific subset of your work can be a headache. If your Jira Service Management and Jira Software instances are separate, they'll have two separate URLs that users have to navigate to. Signing into multiple locations and using different URLs adds an extra step where there need not be one.

Since you've already made the great decision to use both Jira Software and Jira Service Management, you might as well reap the benefits of the easy connection between the two so your teams can focus on what matters, rather than managing their tools. 

Are you looking to merge your Jira instances? Contact us, we know all about how to do that, and would love to help.

Topics: jira atlassian blog optimization tips integration project-management jira-core merge jira-service-management
4 min read

What's the deal with Atlassian's Jira Cloud migration tool?

By Bradley Ode on Jan 14, 2021 10:45:00 AM

Blogpost-display-image_Whats the deal with Atlassians Jira Cloud migration tool (1)Atlassian's Jira Cloud is more popular than ever as companies continue to see the benefits in cloud-based technologies. For those of you already on server, the latest announcement from Atlassian might prompt you get to a head start on looking at migration options. I had the opportunity to work with Atlassian's Jira Cloud Migration Assistant (JMCA) earlier this year and now is a more pertinent time than ever to share those findings. 

What is the Jira Cloud Migration Assistant?

Jira Cloud Migration Assistant is an add-on introduced by Atlassian earlier in 2020 to help clients migrate their data from Server to Cloud. It is a migration assistant and should be viewed as such. There are many things that JCMA does well, but it does come with it's limitations and should not be viewed as a one-and-done solution for most organizations. With that being said, companies with small Jira Server footprint will get the most use out of the tool.

At a glance

What can it do?

  • Jira Software and Jira Core Project data
    • Details
    • Roles
    • Screens and Schemes
    • Workflows
      • Most native workflow functions
  • Issue data
    • Most custom fields
    • Issue history
    • Rank
    • Worklogs
    • Attachments
    • Comments
  • Boards linked to projects being migrated
  • Active users and groups from User Directories

What are the limitations?

  • Jira Service Management- no Jira Service Management data can be brought over with JCMA at the time of publishing
  • Third party app data
  • User Avatars/Timezones/Passwords
    • Passwords will need to be reset after migrating unless the client is using SSO
  • Global configuration items
    • Since JCMA operates at the project level no system settings will be brought over
  • Certain custom fields
    • Single and Multi-version picker
    • URL
    • Select List (cascading)
    • Select List (multiple choice)
    • Project picker
  • Certain workflow functions
    • Validator: required field, field changed
    • Condition: user in group, in project role, field value, subtask blocking
    • Post Function: clear field value, update custom field, copy value from other field, delegating
  • Links to entities that are not migrated

I don't have Jira Service Management, but what's this you say about app data?

Unfortunately, Marketplace Apps will need to be handled on a case-by-case basis. The JCMA tool provides a mechanism for assessing which apps can be migrated from server to cloud, but does not migrate the data via the tool itself. Instead, the tool will scan your instance and provide links or paths (i.e. instructions) to external documentation if it exists.

These paths can be a bit confusing as you are taken to the individual app vendors' sites. These can be radically different from app to app. In our case, many apps did not have a path forward and, instead, we are prompted to contact the vendor.

What about users?

JCMA will bring over all active users and groups on each migration initiation (which may or may not be what you want). You have the option of giving the users product access before running the migration, but in my opinion, it is best to wait until after the migration in case things go awry. After running the migration, the users will need to be invited to the Cloud site.

Should I use JCMA? Or perhaps another method like site import?

When the instance to be migrated is small, well managed, and with little complexity, the JCMA tool will handle your data with finesse. The JCMA tool is also more useful in merges when you are trying to merge a small, relatively simple Jira Software Server instance with a larger cloud instance. This is due to the fact that the JCMA tool itself is very project-centric. However, an abundance of app data, complex workflows, and many external integrations can be some of the things that might stop an organization from using this tool. If you are in any way unsure, contact us -- we've got your back.

My Experience

Overall, I found the JCMA tool to be a simple and effective way to transfer small amounts of project data to a cloud instance. It does what it says it will do, with only minor hiccups along the way. My experience a few months back is likely going to be different with yours as Atlassian continues to invest heavily in Cloud offerings. As always, do your own reading and don't be afraid to ask for help.

Further Reading

Topics: jira blog migrations cloud atlassian-products
2 min read

Confluence Spaces: Rightsizing for Maximum Effectivity

By Brian Nye on Jan 11, 2021 3:45:00 PM

Blogpost-display-image_Confluence Spaces- Rightsizing for maximum effectivity

Your company has decided to make Confluence your collaboration platform, and you've been asked to get this thing going. Where do you start? Don't worry, you are not alone. Trying to figure out what makes up a Confluence space is a struggle that many people have when getting started with Confluence (and even for those who've had it for years). There are two questions that should be asked to help make the decision: What's the purpose of the space and who will be using the content? Once you get the answers, you'll be on your way to setting up the perfect space for you.

What's the purpose of the Space?

Confluence and Jira will be working hand-in-hand to get work done. Because the two applications work so closely together, it is important for the information to be organized in a way that will allow users to draw parallels between the two applications. The best practice is to create a Confluence Space for each Jira Project. By doing this, users are able to create and find information quickly and easily. This mapping will allow users to first create the ideas in Confluence that will relate to Jira Issues as the ideas mature. Confluence can then be the home to the reports of the products or process as the issues are worked and closed. This prevents guesswork from trying to figure out where content should live or where to find information in the future. 

This is not a hard and fast rule, as there may be reasons for having multiple spaces for a single Jira Project, but those should be edge-case scenarios and not the norm. It is highly recommended that users do not create a space based on a single user or group's access permissions. Confluence Space permissions, along with page restrictions, can often satisfy the need to keep information segregated. There may be times that one Confluence Space represents multiple Jira Projects when the projects are closely related. If this is is the case, be sure that the structure is clear so users can find the information quickly.

Who will be using the content?

Spaces don't always need to have a related Jira Project in order to created. Sometimes, a Space needs to be there to coordinate the thoughts of other entities like a Team or Department. For example, my Team may want to document how we are going to improve our Agile process. This is not something that others will care about when they are looking at the Space of the product that team happens to be building. So rather than having one large space that contains all the things the Team is doing, split the space with a clear distinction based on who will use the content. 

Last but not least, socialize the decision

Don't forget that you are not alone in your Confluence instance; others in your organization are likely feeling the same! Be sure to take action by clearly naming Spaces based on what their purpose is to the business. Feel free to add Space Categories and Descriptions to help other navigate more easily to your content. Following these simple rules, Praecipio Consulting has helped other companies organize their Confluence into a more productive and manageable application.

If you have questions on Confluence, Jira, and how these two amazing Atlassian tools can work together in your organization, contact us and one of our experts will get in touch with you.

Topics: jira confluence
3 min read

Jira Align Jumpstart: What to expect

By Brian Nye on Dec 31, 2020 10:30:00 AM

Blogpost-display-image_Jira Align Jumpstart- What to expect

Do you want to roll out Jira Align in your organization but are not sure where to start? The answer is simple, use our Jira Align Jumpstart solution. This solution will give you access to a Solutions Architect who will walk you and your core team of Jira Align practitioners on the setup of your first Program in Jira Align. 

As part of a Jumpstart, there are five phases that you will go through:
  1. Discovery
  2. Set-up
  3. Implementation
  4. Training
  5. Launch

Discovery

The first phase of a Jumpstart is Discovery. During the discovery phase, your Jira Align Solutions Architect will get to know your company. The goal of this is to understand where you are in the scaling process and to get your leadership engaged in communicating the reasons that you are implementing Jira Align. A large part of this will be driven through the value drivers exercise. In this exercise, the team identifies common goals for the organization's agile journey. The output of this exercise will give the whole team a better understanding of the functionality that will need to be configured inside Jira Align and identify how your Solutions Architect can help guide you through that journey. 

Set-up

Following discovery is the setup phase. The setup phase will establish all the connections and settings needed to support your business. The Solutions Architect digs into the integration between Jira and Jira Align, making sure the two systems can pass information between one another. During this phase, there will be a lot of toggling on and off the various features and permissions for each of the user roles. This is based on the goals of the value driver exercise and the roles and responsibilities of the various levels of management using the tool. At the end of the set up phase, Jira and Jira Align will be connected.

Implementation

Connecting the two systems isn't all you have to do! To have the tool set up for your teams, you need to have some base data present to make sure it's working as expected. During the implementation phase, the Solutions Architect will work with Program Management to configure the initial teams and program data. This includes setting up initial strategic snapshots, goals, themes, epics, and features. The Jumpstart focuses on Program-level implementation, but basic configuration for some high level roll up is also included. Based on this data, we will see the flow from the work in Jira pushed up to Jira Align and changes in Jira Align, pushed down to Jira. Although this sounds like a simple task, it usually involves fine tuning some processes to ensure that reports and structure align to the goals established from the project onset.

Training

As the saying goes, a fool with a tool is still a fool. To avoid this, training is done with the teams who will be using the system. There are various types of training that are done with the team. One is for program management so they know how to use the tool from a day-to-day basis. Other training targets Jira Align Administrators so that they understand how the back end is configured and how to maintain the system following the Jumpstart. Both trainings help establish the fundamentals needed for working in the system.

Launch

Now that everyone is prepped and ready to go, all you need to do is launch the program officially. This is targeted to align to a PI Planning session. Now that your having these "Big Room" meetings virtually, you have a tool that will help facilitate the overall direction for your next Program Increment. 

What's next? 

If you want to know more about Jira Align Jumpstart and how to launch the product successfully, contact us here at Praecipio Consulting. We would love to chat with you about your situation to make sure that you are set up for success. Many clients are looking for better ways of scaling with Atlassian, and we would love to understand your current processes so you make the decision that is best for your business. 

Topics: jira digital-transformation atlassian-solution-partner jira-align
4 min read

How is Confluence Cloud different from Server/Datacenter?

By Morgan Folsom on Dec 18, 2020 1:06:00 PM

Blogpost-display-image_How is Confluence Cloud different from Server-Datacenter-

If you've recently moved from a Confluence instance that was hosted by your organization to one on Atlassian's cloud, you may be noticing some differences in how the tools work! The experience is quite different, and we know that can be a bit overwhelming if you've spent a lot of time getting used to the server UI. The change will require some adjustments, so we've provided a quick overview of things to keep an eye out for so you can get back to expertly collaborating with your team.

Navigation

Let's start with getting to Confluence! You can of course access your instance via the new link provided by your IT team https://yourcompany.atlassian.net. But, if you're looking to get to Confluence from your linked Jira instance, the application switcher looks a little different. The application switcher now lives in the grid icon(Screen Shot 2020-04-17 at 11.09.36 AM). Select that and you can navigate to any linked applications, including Confluence. 

Creating pages

Page creation looks different in the new view - you'll notice that there is now only one option to create pages, the Create button. This functionality has made it a lot more intuitive to create pages from templates! In Server, users need to consciously make the decision to create from a template (selecting the '...') or a blank page. Now when creating pages available templates will appear on the right, allowing you to filter and search through templates. With this new navigation you can even see previews of the templates before you select them. 

Keyboard shortcuts

This is the change that threw me off the most when switching between the products, because I rely very heavily on shortcuts! Here are three that I use a lot that have changed:

Action
Server/Datacenter
Cloud
Insert a Macro { /
Start an ordered list 1. 
Change header level Cmd/Ctrl + 1/2/3... # / ## / ###

 

To see a full list of shortcuts, you can select Cmd/Ctrl + Space while editing a page and a dialog will appear and display all of your options. 

Page layouts

The experience in Confluence Cloud is more mobile friendly, so pages are more narrow by default than previously. However, you can still expand your pages to span full screen if you've got a lot of content. Opening the page layout options hasn't changed - you select the icon in the editor. However, the page layout editing experience has changed so you can work on it within the body of the page, instead of at the top.

Screen Shot 2020-04-17 at 11.24.48 AM

You'll notice the arrows pointing out - those allow you to span full screen for either the entire page (top) or the specific section (bottom). The same options to edit layouts are available but you can see them in-line instead, which makes for easier navigation while working them into your pages. 

Panels

The Panel macro is one of my favorites - I like the ability to break the page up visually, and they are a great way to do that. Atlassian has revamped how panels work in Cloud so that instead of having separate macros for different types of panels: Panel, Info, Warning, Note, Success, etc. they are all just one macro, and you can switch the coloring as needed by selecting different icons. 

Screen Shot 2020-04-17 at 11.28.05 AM

Macros while viewing a page

The last change I want to highlight is perhaps my favorite. When editing Confluence previously, you might've noticed that when you insert macros, many of them appear different while editing vs. viewing the page. In cloud, we now see that macros like the Jira Issues macro pictured below actually shows the content while editing now. 

Screen Shot 2020-04-17 at 11.31.30 AM

Switching between tools or views can be tough, but with Atlassian's cloud platform you'll see a lot of changes that make the user experience run more smoothly. Now you've seen some of the changes, you're ready to hit the ground running!

Thinking about switching to Cloud? Contact us to talk about how we can help!

Topics: jira atlassian migrations server cloud data-center confluence-cloud
4 min read

Should I run my Jira Data Center on Linux or Windows?

By Yogi Kanakamedala on Oct 14, 2020 12:29:22 PM

Blogpost-display-image

This is a debate as old as the Operating Systems (OS) themselves and a discussion that never seems to end. Being in charge of making the decision between Linux or Windows for your team can be a hard choice. Currently, about 77% of all personal and professional computers around the world run Windows, while only about 1.84% of all computers run a Linux distro. Linux is the current choice of many organizations because of their development machines and servers. JIRA can run on either OS, with only slight differences as to how the software is managed and monitored. Linux offers better ability to write one-off scripts and utilities. It is important to note that Atlassian does developments and testing on Linux systems. Even though windows historically has performance issues compared to Linux, the gap has been reduced in recent years. Potential problems that Windows users face can be getting backups or processing data. Let's dive further into each OS and learn more about them! 

Operating System Overview

Before making any decisions, it is important to know the history, pros, and cons of each OS. 

Linux

LinuxLinux is an open-source, OS created by a Finnish student, Linus Torvalds, in 1991. This free and highly customizable OS is currently the choice of many organizations, large and small, as their development machines' and servers' OS. Most of the different flavors of Linux, called distributions or 'distros,' are built to use fewer hardware resources, making the overall system more efficient. Additionally, Linux is easy to customize and modify to the liking of the user due to the fact that the source code for it is available publicly. 

Because Linux is completely free, there is less traditional "technical support" available with the product. The available support comes in the form of paid support from a third party or from the Linux community through public chat boards and FAQ sites. Not all versions come with long-term support due to a slow rate of change when it comes to OS upgrades. 

With customizability and freedom to modify as needed comes with a steep learning curve. For example, remote access requires command-line knowledge. This is less intuitive than Windows graphical remote access interface. System changes and customization requires complex operation. 

One of the benefits that comes with an open-source OS is security. With many eyes around the world looking at the source code and improving it everyday, less and less attack vectors are found by malicious parties. Another reason for better security is obscurity. Linux, when compared to Windows, has considerably less market share, making Linux systems less of a target for attacks. 

Linux also offers some additional benefits. It is very easy to write custom scripts, users have full control on updates and changes, and lightweight architecture helps with performance.

Windows

windows

Windows is a for-profit product and was first launched by Microsoft in 1985, gaining popularity with the release of Windows 95 in 1995. This propelled Windows into being the leader of OSs around the world. One of the reasons for this popularity boom is the easy to use graphical interface that Windows is known for. Windows is usually the choice for novice and business users, as well as large companies looking for quick responses and dedicated support. As with all proprietary technologies, individual users experience less customization. Additionally, the OS is not going to be as optimized to hardware as Linux. 

When the OS is purchased, Microsoft provides integrated and online help to all customers. Getting personalized help is usually easier with Windows than with Linux. Due to the market share of Windows, almost all software products are designed with Windows in mind. Some Windows programs are simply not available in Linux. It is important to note that even while many third-party products are free, the majority of Microsoft products are only available at a cost. 

Windows was designed with ease of use in mind. Graphical interfaces are available for making most configurations. For example, to access remote servers, Windows offers a graphical remote desktop software. There is no need to be a command-line expert to customize the server. The learning curve for Windows is not as steep as Linux. This is really important for novice users and more proficient users may be frustrated by the lack of fine-tune control over the system or by the oversimplification of system tasks. 

Due to the popularity of Windows, the OS is a large target for malicious parties. Many security vulnerabilities and system instabilities have been reported throughout the years. To be fair, Microsoft has been able to make security improvements in response to the security leaks. Regular system upgrades and security fixes help protect sensitive data. 

So, should I run my Jira Server/Data Center on Linux or Windows?

As with many hard questions: it depends. Windows is more user friendly. The built-in remote desktop access makes it simple to make changes and update JIRA configurations. Linux servers may have a sharper learning curve and feel more demanding, but they perform better. Linux provides more customization options while working with JIRA and better security.

jira

The decision comes down to one main factor- comfort level. Having prior knowledge of Windows or Linux servers will go a long way in helping make the decision and will make working with JIRA easier. How comfortable is the team with each OS? It is also important to consider the style of the rest of the organization, as OS consistency is incredibly important for productivity and collaboration.

If your organization just wants to focus on development and not worry about managing JIRA, Praecipio Consulting can offer expert support services with our Atlassian Platinum Enterprise expertise and process focus. 

 

Topics: jira best-practices linux windows server
3 min read

Why Jira Won't Make You Agile

By Morgan Folsom on Sep 2, 2020 12:15:00 PM

Blogpost-display-image_Jira Wont Make You Agile

It's no secret that here at Praecipio Consulting, we love Atlassianwe love Agile, and we especially love using Atlassian tools to Agile ends. The Atlassian suite (Jira, in particular) has been built to reinforce a lot of the concepts that are core to functioning in an Agile way, which is one of the many reasons that 83% of the Fortune 500 use it. So, setting up Jira is often one of the first steps companies take when they want to adopt the Agile framework. 

However (and this is a big one!), Jira, or any other tool, should absolutely not be the first step in your Agile transformation. 

Here's why:

Tools Won't Change Mindsets

If you've ever happened upon the Agile Manifesto, then you might guess where I'm going here. The very first line of the Agile Manifesto reads:

"Individuals and Interactions OVER Processes and Tools"

Agile is not something that you "do" to an organization by giving your developers Jira and having daily status updates that you call stand-ups. Rather, an Agile transformation is the process of rethinking how you deliver value to your customers from the ground up. It might sound like a big undertaking, and that's because it is! There's a good reason that "transformation" is the word we use to describe this process (I could insert a cheesy metaphor about butterflies, chrysalis, etc., but I think you get the idea). Now, while part of successfully running an organization means identifying tools that help your employees do their jobs well, the function of your process and tools is to support the individuals and interactions. 

Sure, we can use Jira to enforce some good Agile practices, but if teams don't know what the practices are or care why they're doing it, you won't get the same value out of them. The tools should be enforcing values that have been established, keeping teams from veering too off-path, but they are simply not an effective way of establishing values in the first place. 

Jira's not broken, you're just not Agile

While Jira can be customized to do almost anything you want, there are some structures in place that enforce Agile best practices. There are small things that work perfectly if your teams are well-aligned to best practices, but are huge headaches if you've got bad practices.

The most common example of this that I see is the struggle to manage sub-tasks in Sprints. Many teams use Sub-tasks to break down stories and bugs into smaller pieces of work. However, Jira will not allow you to close a Sprint if you've got stories with open sub-tasks. From a process perspective, this makes sense - your story isn't done until all of the work is done, which means you don't get credit for a story until it, and all of the work beneath it, are Done. Teams fight against this, wanting partial credit for the story that's not been completed. Ultimately, the problem here is not Jira - Jira is enforcing a good practice. The problem is the underlying process - maybe the team hasn't had the discussions about the Definition of Done, or they are getting pressure from above to complete a certain number of story points in a Sprint, or QA is not part of the team, so they're hitting bottlenecks along the way, etc. 

Examples like this come up often. Jira will enforce some fundamentals, and your failure to meet those minimum lines can make it look like the tool doesn't work for you. We can see another example in this hotly-debated blog titled Jira is an antipattern. This article posits that the use of Jira is a good sign that an organization's off-track, and while we explicitly disagree with the thesis, it highlights effectively why Jira cannot be the driver. Trying to use a tool to drive your Agile transformation can easily make it look like the tool is the problem, obscuring the underlying changes that need to be made. 

Ultimately, Jira is a great tool for supporting those Individuals and Interactions the Agile Manifesto highlights, but it is essential to remember that's just what it is: support. Trying to use Jira to drive your Agile transformations sets your teams up for failure if you're applying those rules and structures before even explaining what their purpose. 

When we say we love Agile, we mean it. If you'd like some guidance in your journey to Agile transformation and how to properly set your teams up for success with Jira, get in touch with the Praecipio Consulting team

Topics: jira scaled-agile jira-software agile

Praecipio Consulting is an Atlassian Platinum Partner

This means that we have the most experience working with Atlassian tools and have insight into new products, features, and beta testing. Through our profound knowledge of Atlassian environments and their intricacies, we can guide your organization as you navigate these important changes.

Atlassian-Platinum-Solution-Partner

In need of professional assistance?

WE'VE GOT YOUR BACK

Contact Us