Each and every month, Atlassian adds new features and bug fixes.
These updates could definitely help you in your Jira journey with your team, and at the very least, its good to be aware of them, as some updates to current functionality may affect how you already operate you Jira.
With that being said, lets review some of the highlights that were released and announced in this last month.
- Renaming epics
In changing epics, you can now use a more fitting name for your higher level goals. You can use the name of features for feature delivery or Quarterly goals if you would like to monitor progressions of OKRs.
In this example, an epic was renamed to be a Feature.
Other changes took place as well, in relation to this change, allowing you a wider set of updates to create a coherent use case.
For example, you to change the EPIC level name in the hierarchy so its correctly reflected in the roadmaps plans.
You can add more epic types to the epic level.
Here, you can see that the epic level is renamed a feature, and it contains 2 issue types)
In the quick filters as well as the backlog panel, the new “Epic” name will appear as well.
Still, there are some other places where the change isnt reflected yet.
Some examples include the create screen, or the soon to be gone (more about that whenthechange is rolled out), epic link
Also, in the backlog view, any non epic type that is added into the epic level, will still appear as a regular item and not an epic type item.
In the above example, the right side item, as a feature which is defind as an epic level item, but it doesnt appear in the epics’ section.
So, while the change is not yet complete in all its possible aspects, its still provides a strong starting point if you want to have a different name type for your team to work with!
When making changes to an issue type name, you should consider its affects in filters, automations and dashboards, to begin with.
2. Viewing forms in JSM requests
Forms are a great way to enhace UX design and introduce logic for when you need your customers to submit information into a requst on a service desk.
Until recently, the connection between a form and a request had only one sided visibility, that was available only on the form. Meaning, that you either had to remember which form was connected to which request, or open the portal and guess your way to the relevant form based on the fields in the request.
In their latest updates, Atlassian is now showing the form in the request configuration and allowing to directly get to editing the relevant form.
With this chang, you can see the form name, edit the form, and remove the form from the request. It is definitely way easier to manage forms with requests now!
3. Automation UX changes.
With this updates, Atlassian addresses a pain point both for jira users and jira admins.
In the area above the fields, you can now find the automations button which allows a user to run any automation that has a manual trigger.
For the admin, though this change hasn’t rolled out everywhere yet, the automation was seperated into its own section. This makes it so much easier to reach to automations to see which rule was run, and makes debugging less of an annoying process.
4. Canned responses for JSM
This is something i’ve been long hearing about and its been a missing functionality for anyone who migrated from the server to the cloud.
With this update, Atlassian allows you to create a set of pre-written responses. This helps to save time by the agent and assure standardization in how your company communicates with its customers.
With canned responses, you can create your own, or allow other agents to use your pre-existing responses. Another cool feature of it, is that you can use parameters from the request itself. Not to get too much into the nuts and bolts, but the list of possible parameters available in the canned response has already been expended by Atlassian and i would expect to see it expand further.
5. SLAs to trigger based on due date.
This is tremendous update that support a specific use case of SLAs, which is definitely common. With this update, you can trigger/pause/stop the SLA based on updates to the due date.
With that, you can achieve an SLA based on when you should only start handling it. You can set the due date to X and only consider the success of the effort/resolution within that time.
Before the change, you could trigger based on comments, assignee update and statuses. Where non of those may properly reflect the actual work, you could easily set the due date once you know it and only then use the SLA to rate your operations.
