Top 5 Jira Service Management Best Practices for Ultimate Efficiency
If you’re using Jira Service Management (JSM), you naturally want to optimize its potential and achieve the best possible return on your investment. These five strategies will help you streamline your IT service desk operations, empower both customers and support agents, and unlock the full value of JSM for your organization.
Here’s what you need to focus on:
IT Service Management (ITSM): Emphasizing the broader context in which JSM operates
Customer self-service: Highlighting the cost-saving benefits of self-resolution
Agent productivity: Tying improved workflows directly to agent efficiency
Jira customization: Stressing the power of tailoring JSM to specific needs
Jira Service Desk An alternate term for JSM, sometimes searched for by users
Maybe you’ve been using this tool, and want to get more out of it.
Either way, observing JSM best practices will get you there. Even non-IT teams like legal, HR, and finance are using it successfully. So how do we distill the top five JSM best practices, given the wide range of teams it works for? We focus on the key features that deliver value to all teams.
#1: Invest in Training
Jira Service Management is a powerful platform with extensive capabilities. Don’t miss out! Thorough training for everyone involved is essential:
Resources: Explore Atlassian’s documentation, blog posts, videos, or even hire consultants.
Beyond IT: JSM benefits many teams, so train all potential users.
Customization: Research plugins, consider custom workflows, or leverage the API to tailor JSM perfectly to your processes.
#2: Optimize Your Customer Portal
Your portal is the face of your service. Make sure it’s a great experience for your users:
Clarity: Clear language, intuitive navigation, and FAQs guide customers to quick solutions.
Request Types: Offer relevant options, starting with the essentials and adding as needed.
Automation: Use hidden fields and automation to route requests seamlessly.
#3: Master Your Queues
Queues are your agents’ workspaces – keep them efficient and organized:
Team Focus: Emphasize team priority queues to promote collaboration.
Personalization: Train agents on starred queues for individual customization.
Balance: Fine-tune queue filters to manage team priorities while allowing agent flexibility.
Visibility: Test workflows to ensure all issues are visible in the appropriate queues.
#4: Harness the Power of Knowledge Bases
The Knowledge Base (KB) feature of JSM is an efficiency tool that gets better with time, and serves both your portal users and your agents — if you let it. When appropriately configured, a project’s KB helps you two ways. First, it lets portal users answer their own questions without taking any of your agents’ time. Second, when an agent is working a request, the KB feature suggests content that might be relevant to that request. Let’s look at those.
Each KB article you create will answer one or more customer questions over and over. As a portal user types in the Summary field of a request form, JSM searches that project’s KB for the text they type, and suggests matching articles.
If a portal user doesn’t happen across the right article in the portal, an agent can easily reply by sharing it in a comment.
You can monitor how effective your KB is, to a certain extent, using the default reports.
“Requests deflected” shows per day how many portal users read a KB article and hit the ‘thumbs up’ button to answer the question “Did this article help?” at the bottom of the page; most users won’t take the time to do that, so that metric is of limited help. But the report also shows how many KB articles are viewed each day, and as you add to your KB, you can track that trend vs. the number of requests submitted, to get an overall sense for how well your KB is helping customers.
For agents viewing a request from within Jira, a Knowledge Base field in the issue will indicate how many articles match the words in the Summary field. That makes it easy to identify articles that may resolve the user’s request. But there’s more!
Under the issue’s details section, agents will see a “Similar Requests” section that lists similar previous requests based on the Summary and Description fields. This is how a well-used KB gets better with time — agents save time on more and more requests because they can easily see how similar requests were resolved, rather than having to figure each one out separately.
#5 Make the System Do the Work
When implementing JSM, it can be easy to focus on agents and how they work incoming requests.
There is not just one, but two ways you can reduce the amount of repetitive work your agents do:
Workflow customization, and Automation.
Workflows are obviously a key feature of all versions of Jira, and you may be familiar with the workflow editor. But customizing workflows goes way beyond adding transitions and statuses, or populating fields, or using whatever predetermined options an app may add.
Jira allows you, through apps such as Scriptrunner, to write your own Java code that executes either in a transition or whenever a system event occurs.
That code, using Jira’s and JSM’s APIs along with any publicly accessible Java library, vastly expands what your workflows can do for you. Complex math, complex logic, complex transformation of field content, integrating with other systems using their APIs — all this and so much more is possible.
Automation is a per-project JSM feature for building simple if-then workflows called “rules” that fire off whenever the defined trigger event occurs. You can configure your own by choosing what event(s) trigger the rule (like “Rule is run when an issue is created”), what additional conditions have to be true (like “Request Type equals Promotion”), then what happens – or you can use built-in templates like “Resolve issues due to inactivity” or “When an incident is created, create a post-mortem page in Confluence.”
Because Automations are just a list of rules that can easily be individually configured and enabled/disabled, they’re generally easier to work with — but you do have to add them to each project. Workflow customizations, on the other hand, may be more involved to work with, but are shareable and much more powerful. Jira Service Management gives you both options.
More Reading in JSM Best Practices
Atlassian’s JSM is a complex product, useful for change management, incident and problem management, service operations and support, and much more. If you want to dive into JSM best practices for different teams and individual features, Atlassian has a good starting place.
Get More Information
To get started, simply fill out the form below with details about what you are looking to achieve. An expert member of our team will be in touch shortly. With Oxalis, you can expect results, not excuses.
A Guide to Effective Resource Capacity Planning in Jira
This article covers how to be more effective at individual and team planning, and how to streamline your project workflows across departments. We’ll discover two approaches to resource capacity planning, and outline the strategies, benefits, and best practices for each. Everything discussed here can be scaled, helping your enterprise function at premiere performance. See how applying effective resource capacity planning can ensure seven instantaneous benefits your business can utilize to function at peak performance.
Table of contents
The Challenge of Effective Resource Capacity Planning
Identify what you really need to know
On a basic level, capacity planning is an obvious need. You don’t want employees tasked with so much work that some of it goes unfinished, and you don’t want employees with too much idle time – especially if others are overworked. How do you find a balance? Companies are looking for solutions to help streamline this flux of workflow. Resolving capacity problems and implementing effective solutions will help your business deliver projects on time and continue to conduct business without workflow interruptions.
Because your organization is unique, you need to be clear on what level of resource capacity planning you’re already doing, and what you aren’t. Let’s look at the following scenarios to help clarify this a bit further.
Maybe team managers have been handling individual resource capacity, but now your organization is growing and you need a larger view across projects.
Are you more concerned about allocating skills, or work roles/positions?
Is there a particular problem or set of problems you want to solve?
Or are you trying to get out ahead of potential problems?
Even in the latter case, you still need to identify which problems you’re most concerned about. Consider whether it would be more useful to group your employees by team, department, role, key skillset, etc. That grouping will affect a lot of the reporting options we’ll be looking at. If you skip this step, it’ll be hard to choose the right tools or know-how to make effective use of the data they give you.
Determine which tool(s) to use
There are, obviously, plenty of tools that either include resource capacity planning as a feature or focus on it exclusively. Two key aspects to consider when selecting a tool are:
Whether the data it gathers will help you with the problems you want to solve
How flexible the tool can display that data in different ways. It may be that the tool’s built-in reporting will meet your needs, or you may need an additional tool to give you more options. We’ll discuss some particular tools later on.
Capture the right data
There are several capacity-related elements you may want to report on, such as the team an individual belongs to, and what projects they’re working on. You don’t want to choose a tool that ignores teams if you want to see a capacity for your team.
Present the data so it tells you what you need to know
Capacity planning is about data – the number of hours employees are allocated to various projects and the hours they worked on those projects. That data can, with the right tools, be displayed in a wide variety of ways. Each of those displays tells a different story, and you want to make sure you hear the stories you need to hear.
Two Approaches to Resource Capacity Planning
The two fundamental approaches to capacity planning are team-based and individual-based. Most organizations will need a combination of the two, but it’s important to understand them separately. We’ll run through how each works using Jira and our favorite tools.
Individual-based Planning and Capacity
This approach probably doesn’t need much explanation, since even a small organization will find it useful to plan each employee’s workload. In order to support individual-based capacity planning with Jira, you’ll need some Atlassian Marketplace addons. Here we’ll cover using Tempo (with Tempo Planner and Tempo Timesheets) plus EazyBI to display the data as we need it.
What You Get with Tempo
Planning
Tempo Planner gives you a number of options for viewing planning data.
The planned hours view in Tempo Planner
Here we see the Resource Planning view.
Each row is a resource, labeled with the Tempo team(s) they belong to, and a column for each day. A red bar in a table cell indicates that the resource has more hours planned for that day than they have capacity, while yellow means they have spare capacity. By default, the allocated hours for each resource are summed across all projects, but you can expand a resource to see their allocation by project. And this is more than a report – you can add planned hours right in the screen.
It’s easy to change the displayed time period, and you can use filters to show only certain resources.
Then there’s the Timeline view, which displays the project each resource has hours planned for, across the chosen time period.
Resource planning in Tempo by project
Planned vs. Actual
Now what happens? People will work, and they’ll log their hours to these specific projects, and the actual data will diverge from the plan. Tempo’s Planned vs Actual report will give you a sense for how closely teams and projects are working to their planned hours.
The default overview in Tempo’s Planned vs Actual report
We have three sections (above):
at the top, total hours across all resources and projects
in the middle, a visual breakdown of planned and actual time by project
and at the bottom, a list by project.
You can filter and group to get more specific. This sort of pipeline overview has value, and is easy to get since it’s built into Tempo Planner. But it’s generic, and may or may not help you identify and track the specific issues you need to. And there are better ways to look at this data.
What EazyBI Adds
When you import the source data from Jira and Tempo into EazyBI, you open up a range of options for visually displaying the state of your capacity plans. Let’s look at some examples of what EazyBI can do for you; note that all these reports require custom setup, so you’ll need to allow sufficient time for that.
Here we see a Planned Utilization view that displays each resource’s planned hours compared to their capacity, to show who has more work planned than they can probably do in that time period, and who has time available to be planned.
Green cells indicate plenty of available capacity, while yellow warns that the resource is close to capacity, and of course red means they’re over-allocated. This makes it easier to move work around and keep everyone allocated properly.
You can expand All Projects to see how the allocation breaks down by project and identify the source(s) of that over-allocation. Take that top left 118.75%, for example.
The Planned Utilization Percentage report with per-project breakdown
Now we see where that over-allocation comes from – the resource isn’t over-allocated for any one project, but just has too much time planned for too many projects. If the work is planned by component, you can expand a project and see that allocation as well. And right-clicking on a cell gives you several options for drilling further into those planned hours.
More right-click options for EazyBI reports
Using the timeline dropdown, you can change the period you’re reviewing, by week, by quarter, by year, and so on.
Now let’s look at what we can do for planned time versus actual time (PvA). Here is a dashboard that provides several options for getting an overview.
Sample EazyBI dashboard – Planned vs Actuals
At the top is this resource graph showing each resource’s planned hours for the time period, actual hours spent, and hours required (e.g. 5×8 hours per week, or 3×10, or whatever you configure in Tempo). This makes the variance between planned, actual, and required easy to see.
Below are two reports, one showing PvA per project, and one showing PvA per month with % Utilization.
Sample report in dashboard – Planned vs Actuals by project
Each report lets you change a parameter, either the time period or the team. These numbers assume they’re required to work 40 hour weeks.
Sample report in dashboard – Planned vs Actuals by team
A closer look at the key idea behind % Utilization
All hours worked are not equal, and whenever you’re looking at all of a resource’s time (rather than by project), you might well be including admin or non-billable time. And that will throw off your numbers. So if your workers are logging their admin time, then you want to make sure you’re comparing planned hours to time actually spent on projects. Therefore, this % Utilization is Hours Spent minus Admin Hours divided by the Tempo planned hours.
At this macro level, PvA reports like this show you how efficiently teams, departments, or other resource pools are operating.
But EazyBI will also give us better insight into the resource level.
Sample report in dashboard – Planned vs Actuals by project and resource
Here we can see, for each project, the weekly planned and actual hours for each assigned resource – along with a visual indicator of how well PvA is adhering to the plan. Or you can collapse the Users and see the totals by project. And the timeline can be per day instead, or by month, quarter, etc., while the Project dropdown lets you narrow the report.
These sorts of advanced capacity and utilization metrics – and more – are possible once you’re capturing the right data and displaying it the way you need.
You can:
Identify departmental bottlenecks and other challenges.
Ensure that all resources are properly utilized.
Keep projects on schedule AND quickly slot new projects into timelines based on when the resources are available.
Improve hiring cadence by planning intake so new hires are in place and ready by the time they’re actually needed.
Schedule project milestones, code releases, and other delivery events efficiently because you see the impact on the teams involved.
And so on.
Setting it up
All this operational goodness is only possible if you’ve set yourself up for success. The following processes are prerequisites.
Reviewing your plan: The value in PvA reporting starts with planning. You need to make sure that all relevant personnel are time planning sufficiently in advance to be useful, and adjust the plans as the situation on the ground changes.
Entering time worked: If work time isn’t logged accurately and on time, then you’re wasting your planning. And accuracy is tied to timeliness since most people’s recollection of what exactly they did a week ago won’t be so good. Ideally, you can cultivate a culture of daily time logging, whether it’s logging time in individual tasks, entering it in a central timesheet, or whatever your timekeeping process is. The good news is that the reporting applications we’ve discussed can also show you when people aren’t logging time, which gives you a way to reinforce the practice.
Being realistic about admin time: Any number of different things can take up an employee’s time, from meetings to emails to chats to phone calls to smoke breaks to bathroom breaks to clean the break room, and on and on. You can’t accurately assess an individual’s capacity unless you know how much time they actually have to work on the projects you’re planning. And this will vary by person! It’s worth putting in the effort to figure this out upfront, whether you use Atlassian’s Capacity Planning exercise or another approach. Without this key piece, you can do everything else here exactly right and still end up with PvA numbers that are frequently off.
Holding regular capacity planning meetings: Capacity planning can be done monthly, quarterly, weekly, or bimonthly – whatever works for you. No matter the cadence you choose, stick to it. Plan around those meetings. The more regularly you do it, the more you’ll get a feel for the process, for what it’s like to plan for that period. Shuffle resources around, address delivery scheduling risks, make performance staff decisions… and do it all with confidence because the data is now there to justify the decisions.
Team-based Resource Planning and Capacity
This approach is suitable for an organization that has reached a certain size. For instance, if you are trying to manage your capacity by only looking at individual resources, you’ll soon find that tactic becomes increasingly ineffective. You’ll have larger projects, larger teams, more levels, and types of teams. So how do you manage this efficiently?
Team-based capacity planning across multiple projects is supported in Jira Cloud Premium out-of-the-box version and up via Advanced Roadmaps (AR). Resource and capacity planning needs arise in earnest when you’re managing capacity across multiple projects, so you’ll want the Premium version. We have a full guide on how AR is set up to be operational. You can define teams that are dedicated to a plan – or the teams can be shared across multiple plans so that their capacity can be allocated in different parts of your portfolio according to your particular needs.
What AR offers for team-based capacity planning
This overview assumes familiarity with Advanced Roadmaps; to learn more about AR take a look at Advanced Roadmaps for Jira: Overview & Comparison or our ON-DEMAND webinar. Be sure to keep in mind that using the word “team” from this point on will mean a team as defined in AR terms, which may or may not match your organizational structure. More on that later.
Team-based planning is easy to access in an AR plan – just choose Team in the ‘Group by’ setting and turn on ‘Show capacity on timeline’. Using AR for planning is an entire topic of its own, so we’ll assume here that you know how and have both created some plans and defined some teams.
This will add a capacity indicator row for each team, using the planned dates from your sprints and the total story points for each sprint. This capacity indicator works no matter what level(s) of issue you’re viewing, from Epic to Sub-task.
The green lines in each cell indicate that the time period is at or under capacity – in fact, the height of the green line shows you how close to capacity that period is. And of course, red lines indicate that the work included in that time period exceeds the team’s capacity. You may need to reduce the timeline displayed in order to see more detail; this can be done in the lower right.
But what exactly does capacity mean here?
Capacity Overview
Generally speaking, the number of story points or hours your team can complete in one iteration is referred to as its capacity. But capacity works differently for Scrum vs. Kanban teams. Let’s define these two types of teams further.
When scheduling work for Scrum teams, capacity is calculated differently for time-based estimates and story points:
If you’re using time-based estimates, the sprint capacity is determined by taking the weekly capacity and multiplying by the number of weeks per iteration. For example, if your team’s capacity is 40 hours and your iterations last two weeks, your team’s sprint capacity will be 80 hours.
If you estimate in story points, no conversion is necessary since story points are defined per iteration. The capacity applies to the whole sprint. By default, this is set to 30 story points, though you can adjust this to meet your team’s needs.
Capacity for Kanban teams
Kanban teams can only use time-based estimates, so be sure to populate the Original Estimate and Remaining Work fields.
For Kanban teams, work is broken down into iterations which each last one week (this cannot be altered). You can set the weekly capacity of a Kanban team in either days or hours, but the length of the iteration cannot be changed. If you set the weekly capacity in hours, here’s an example of how AR converts that into days: a weekly team capacity of 30 hours is 3/4 of the full 40 hour work week, and 3/4 of a 5-day work week is 3.75 days, and if the team has 6 team members, the weekly capacity in days is 3.75 X 6 = 22.5.
Assessing Your Capacity
You can view a popup summary of each period (sprint or iteration) in the chart by clicking on it. Here’s what that might look like for Kanban – note that you can change the capacity of that period by clicking on the capacity number, e.g, the 25 in both these examples
Let’s take a closer look at this important feature.
Sprint information – Name, start and end dates, status lozenge, sprint goal (as defined by administrator), and total sprint capacity
Progress bar – Story points allotted and completed
Further viewing options for this sprint
For over-allocated time periods, if you expand to show the issues and add the Original Estimate field, or Sprint and Story Points fields, you can easily use AR’s regular planning functions to move issues around, adjust work estimates, start and due dates, etc.
How Capacity Decrements
When an issue is added to an iteration, it will consume the estimated value (story points or days/hours) from the capacity value set by your administrator. Issues that span multiple iterations will consume all remaining capacity of the first iteration before moving on to the next one. Capacity is assigned on a first-come, first served basis – meaning that pre-existing issues won’t be moved. This is true whether you’re using story points or time-based estimates.
Assigned issues that consume more capacity than is available in an iteration will generate a warning (if those are turned on). We recommend that any assigned issues that have an estimation value higher than the capacity be broken down into smaller subtasks or spread across multiple iterations.
Note that issues with start and end dates that fall within a sprint will consume capacity, even though they’re not assigned to that sprint. When monitoring capacity, these issues are marked with the label x issues not assigned to a sprint.
What This All Gets You
Now you can accomplish several capacity-related tasks:
Measure the capacity of one particular team.
Measure one team’s capacity, then manage the effect of that team’s capacity on other multifunctional teams.
Determine how many hours you have available in a certain role or skill set, say project manager or developer.
Identify where you need to resource up or scale down depending on over-allocation or under-utilization.
The visual capacity warnings are updated live as you click and drag to add scheduling – even at the Epic level.
Generally, most enterprises and other sizable organizations need to understand where they’re deficient in one particular skill set or resource.
But wherever the capacity is that you want to manage, structure your teams to ensure that capacity can be measured.
The team-based model is a more scalable model, which is increasingly important the larger your organization is, and helps you with larger-scale challenges like staffing. If, however, you have unique resources, skillsets that don’t exist as a pool, then team-based capacity planning can break down – you need interchangeable resources at all levels and skills. The ideal scenario for team-based capacity planning is tracking what teams can actually execute on, and calibrating their availability based on their past performance.
The truth is, even with effective team-based planning in place, most organizations – even enterprise or large departments – will still want some level of individual capacity planning, to know what’s happening with specific critical resources for their projects and if those resources are being over-allocated or under-allocated.
Setting it up
There are several key configurations for effective team-based resource capacity planning in AR.
Setting up the right teams: You can use AR’s Teams to reproduce your Scrum or Kanban teams, or you can group people into skill sets, resource types, etc. Just think it through, because whatever you can’t manage the capacity of something you don’t configure here.
This is important even if your teams are cross-functional, like sprint teams of various types of resources, in which case your AR teams won’t match your teams in reality.
Choosing the right issue sources: Your plan must be configured to use the relevant team boards as the issue sources, so that the plan has access to the sprint information, like velocity.
Matching the team to the board: Each team in your plan must be configured to use the appropriate board as the associated issue source. If you create your plan using the team boards, this will happen automatically, otherwise you have to do it yourself.
Setting the team’s velocity (Scrum): If you’re doing sprints, each team’s sprint velocity must be set, since that is AR’s measure of actual work achieved; make sure it’s based on historical data, and not on guessing or wishful thinking.
Populating Story Points (Scrum): If you’re doing sprints, your teams must be strict about setting Story Points, since that tells AR how close to capacity each sprint is. Without this, you risk over-allocating sprints and not getting it all done.
Populating Original Estimate (Kanban): This serves the same purpose for Kanban as Story Points do for Scrum.
Keeping Work Remaining Accurate (Kanban): If AR thinks there’s more work left to do than there really is, then your resource capacity planning will be off. So everyone has to be diligent about updating the Work Remaining field.
Results and Benefit to the Organization
We’ve identified seven benefits your enterprise will experience when you are engaged in effective resource capacity planning. You will:
Keep all your employees working near their capacity, without either becoming a bottleneck or sitting idle.
Ensure resources are allocated where they’re needed most.
Keep all your projects, initiatives, etc., on track with realistic end dates.
Simplify re-allocating resources and work to different sprints or iterations.
Make it easy to slot new projects into timelines based on when the resources are available.
Improve hiring cadence by planning intake so new hires are in place and ready by the time they’re actually needed.
Schedule project milestones, code releases, and other delivery events efficiently because you see the impact on the teams involved.
In this data-driven world, capacity planning data opens the door to a new level of operational success.
Get started with the tools your team actually wants to use
Inevitably, enterprise-level tools like Tempo Planner, EazyBI, and Jira’s Advanced Roadmaps have more to offer on resource capacity planning than any one article can reasonably cover.
We get it. Your organization has unique workflows that constitutes smart solutions, freeing up valuable time for your teams to operate more efficiently is more important now than ever. The team at Oxalis is here to help you transform processes within your organization – get started today.
Advanced Roadmaps for Jira: Overview and Comparison
What is Advanced Roadmaps for Jira?
Note: This article presumes some familiarity with Jira Software and agile concepts.
Advanced Roadmaps for Jira (“AR”) is a cross-project planning tool for Jira Software that is built into the Cloud Premium and Enterprise versions – as well as Data Center versions 8.15 and up – and expands the capabilities of the basic Roadmaps feature in Jira Software. Since Atlassian is continuously enhancing this invaluable tool, it’s easy to have questions about AR’s capabilities and how to best utilize them to optimize your business. Who is Jira Advanced Roadmaps for? What are its major benefits?
Table of contents
Advanced Roadmaps for Jira expands your options and gives you greater control over your planning.
Is your team’s planning taking up too much of your time hindering work productivity?
Are you sure your resources are being used effectively?
What can you accomplish with AR capabilities?
We will look at eleven improvements AR can instantly apply to your business model. Let’s dive into the specifics on Jira’s Advanced Roadmaps and navigate the most frequently asked questions you may be experiencing. We will also be comparing the pros and cons and key differences between Structure.Gantt, Big Picture, Tempo Planner, and Advanced Roadmaps. Which system will work best for you? See our Solutions Comparisons Chart below.
Roadmaps are a Jira Software feature that provides Jira with Gantt charts to visualize data from one team’s issues in a single project. They work with Epic, Story, and Task issue types, in a customizable interface that allows you to: see custom fields, each issue’s type, name, and status; view the Gantt chart including dependencies; and update issues without leaving the chart. And because a roadmap accesses your existing boards, projects, and filters, it always provides real-time data. These simple planning and dependency management features help your teams better visualize their work and manage it better together, so you can release more predictably while staying on target to achieve your goals.
Building on the roadmap feature in Jira Software, AR enables project planning across multiple teams as well as providing additional features for larger organizations.
What can you do with Advanced Roadmaps capabilities?
The benefits of this software are vast. You can plan work across all teams and projects, identify dependencies, adjust plans based on resource capacity, explore alternative planning scenarios, create custom plan views for differing audiences, and give everyone in each team the same visibility based on the real-time work they’re doing in Jira Software.
Advanced Roadmaps for Jira expands your options and gives you greater control over your planning. You can: define only the issue sources, statuses, and releases you want your plan to incorporate; add as many additional levels to your issue type hierarchy as you want; build plans that include roadmaps for as many teams and projects as you want; and more.
Plan and track work strategically across multiple teams and projects
Help multiple teams collaborate together
Track the big picture
Enable a single source of visibility across planned work for everyone, so that priorities are understood and shared
Identify dependencies across large pieces of work that can impact your timeline (even if they live outside your plan)
Plan based on team capacity and velocity, scheduling work at a pace your teams can handle to ensure that your plan is attainable
Empower teams at scale
Manage competing priorities
Set business goals and track progress towards them
Explore alternative scenarios, whether to determine more effective arrangements of work or to determine how a potential future event might affect your capacity, timelines, etc.
Who Should Use Advanced Roadmaps for Jira?
Generally speaking, large to enterprise businesses with large portfolios of work will benefit most from AR’s advanced planning capabilities. Any user with permission can also create a plan for personal use or for team/project purposes to track dependencies at any scale.
Existing Jira Software Users
If you’re already using roadmaps in Jira Software, and find yourself up against the following limitations, Advanced Roadmaps will let you plan larger.
Solve Common Problems
If you’re not already using Jira Software, Advanced Roadmaps for Jira can help you solve some problems that organizations often face.
Are your resources being used effectively?
Project managers and administrators (along with scrum masters and those in SAFe roles such as product owners and release train engineers) are often asked when features, upgrades, and systems can be delivered. Even in an Agile environment using scrums, with deliverables broken into sprints, you still need to know when they’ll be delivered, whether they’re on track, and if you have enough resources.
AR shows your forecasted release dates so you can see dependencies and capacity bottlenecks, and understand the current situation as well as future activities and their statuses. It also lets you play with different versions of your plan to see how various factors may affect delivery dates.
Every hour spent creating spreadsheets or Gantt charts is time not working towards releases – and by the time that hour is done, employees have done more work that makes those spreadsheets or Gantt charts out-of-date. Unpredictable factors like holiday plans and illness, or team members being reassigned between projects, can quickly render a static plan obsolete and require inconvenient rework.
Advanced Roadmaps for Jira provides a clear view of who’s doing what, and when, showing project progress and backlogs based on real-time data. The moment someone finishes a task early – or misses a due date – you’ll see how that affects the rest of your plan. The Teams and Capacity features let you group, filter, and allocate work based on assigned team members and their availability as it changes.
Spending too much time providing updates to higher-ups?
Stakeholders who aren’t involved in the day-to-day detail of a plan still need to know who’s working on what, and often want meetings to get an update on the current status. Again, those meetings take time away from productive work toward deliverables.
AR enables different views of a plan that are tailored to specific audiences, so each level of management can check real-time status at the level of detail they need, whenever they need it. You won’t have to trade off progress visibility for team overhead.
A plan combines the roadmaps of multiple teams working across multiple projects, and ladders them to company-wide initiatives. It provides a shared source of truth that outlines organizational goals and communicates a path for teams to achieve milestones and key results.
The benefit of using a plan is that it establishes the bigger picture and shows how a team’s work relates to the work of other teams. It visualizes how each team contributes to broad organizational goals, and enables you to identify potential bottlenecks and conflicts so you can adjust before they cause problems.
Unlimited Issue Type Hierarchy
A hierarchy connects small, process-based tasks to cross-functional deliverables, and escalates them to broad organizational objectives. Depending on how your work is structured, hierarchy levels represent different levels of detail in a plan’s scope and show how they’re related.
AR allows you to ladder work from multiple teams and projects to company-wide initiatives. With the freedom to create unlimited levels of issue type hierarchy above Epic, your teams and organization can plan smarter.
Saved Views and Smart Filters
Saved views allow you to tailor your plan for different audiences. Customize your plan to emphasize different aspects, then save it as a view that can be easily accessed at any time.
This is particularly useful for large, cross-functional projects, where different stakeholders view your plan with specific concerns or needs in mind. With a single view of important initiatives, you can plan and track how you’re making progress on the big picture across multiple teams.
Smart filters ensure you can always share the right data of your roadmap for every stakeholder.
Find and refine your roadmap by searching for keywords and filter by assignee, status, label, or issue type.
Together, smart filters and saved views let you keep everyone at every level up to date on the plan – in the exact way they need.
Dependencies
Dependencies show the relationship between issues in your plan, such as contingencies and blockers. A dependency can be incoming or outgoing, revealing when an issue blocks other issues, or is blocked, and what issues to prioritize to ensure that work progresses. They are shown on the timeline by badges, columns, or lines.
Visualizing and understanding dependencies is vital when project or program managers determine a critical path in the roadmap. When dependencies are thoroughly mapped, a team can adapt and plan for alternative paths. Track dependencies across teams, projects, and initiatives to get ahead of blockers across your organization.
You can also view dependencies in the Dependencies report tab, which visually maps relationships between issues in your plan.
Alerting: Advanced Roadmaps will alert you if a team is booked over the assigned capacity, or if a project is past its end date yet still in progress.
Capacity reveals the units of work that a team undertakes in a given period of time. It can be used to estimate a team’s ability to complete work by a particular milestone, and is invaluable for evaluating risk when making key decisions.
Capacity is added to the plan by team and domain leads who regularly assess their team’s availability, resource allocation, and the prioritization of other projects. Keep your goals on track by accounting for whether your teams have bandwidth to complete the work they’ve scoped. See multiple teams’ capacity on a sprint-by-sprint basis.
Scenarios
Scenarios allow you to explore alternative paths to milestones or project completion. Planning with different scenarios allows you to adapt with minimal disruption. You can aim for your best case, plan for your worst case, and be prepared for anything in between.
A scenario is like a copy of your plan, complete with its own set of data, and any changes you make won’t affect the “live” plan unless you choose to save them to it.
Issue sources and Exclusion rules
Issue sources determine what data will be used in Jira Software to create a plan. They outline the work to be done and the problems you’re trying to solve. Issue sources are first selected during plan creation and can be adjusted at any time. They include boards (scrum for planning sprints or kanban for work planning based on available weekly hours), projects, and filters (saved searches in Jira Query Language).
Exclusion rules allow you to refine your plan’s issue sources so the most relevant issues are displayed. Depending on your focus, you can set rules to exclude specific issue types, statuses, or releases. You can also adjust how long you’d like completed issues to stay in your plan.
Together, these parameters help you right-size your plan and prevent irrelevant data from cluttering it up.
Advanced Roadmaps Compared to Similar Solutions for Jira
As you might imagine for something as vital as planning tools, Advanced Roadmaps is not the only solution available for Jira. Atlassian’s marketplace offers a number of alternatives, and here we’ll take a look at three popular choices and how they compare to AR.
All these products have a wide array of features, and it’s beyond the scope of this article to touch on all of them. We’ve tried to highlight the significant features that in our experience will affect the most organizations.
BigPicture
BigPicture describes itself this way: “BigPicture is the leading Portfolio, Product, and Project Management application for Atlassian Jira. It gives managers unprecedented clarity of information, helps them neatly visualize even the most complex initiatives, smartly distribute workload and allocate resources, efficiently coordinate work of teams, easily report on progress, and ensure perfect strategy-to-execution alignment at all levels. The system supports agile, classic, and hybrid management methodologies and allows for combining them freely at the portfolio level. BigPicture is the go-to PPM solution for any forward-thinking organization before, during, or after digital transformation.”
Three Basic Concepts
BigPicture is a distinctive solution that can take some time to understand, so the following concepts should give you a good overview.
The Box
The fundamental organizational concept – and data object – in BigPicture is the Box. A Box can be thought of as a fancy customizable data container, or folder, that can contain a full spectrum of project management objects for differing PM approaches (e.g., you can mix Agile and Waterfall), and that can contain other Boxes. The possibilities for Boxes include: SAFe ART, Portfolio, Task, Resource, Risk, Scrum project, stage, iteration, and more. Each level of your Box hierarchy comes with its own set of views on the state of the work in that Box. The point being, at each level you can get “the big picture” in a variety of ways, such as that level’s own Gantt chart, or Scope overview, etc. — and each of those views can be customized. BigPicture comes with a set of built-in Box types, but you can create your own. Each Box type has its own default Status as well as one or more default parent Box types, enabling default hierarchies.
The Task
In BP, all Jira issue types are called Tasks. Separate from the Box hierarchy is the Task hierarchy, which is an ordered list of elements BigPicture uses to determine the hierarchy. You can use built-in elements like Project, Epic, Version, Component, and Sprint, or you can use a Jira link type to define the parent/child relation. By default, the Task hierarchy is defined per Box type, but an individual Box can be configured with its own Task hierarchy.
The Module
A Module is like a specialized filter that shows a distinct view of a subset of the data in a Box, such as Overview, Gantt, Scope, Board, Roadmap, Resources, Team, Risks, Calendar and Reports. Each module can be turned on or off for each Box type.
As an example, the Resources module displays which individuals and teams have been allocated to what, and you can freely change their allocation or the tasks they are assigned to directly in the add-on. These changes are synchronized not only with Jira issues but also with other relevant modules like Gantt.
Putting Them Together
When you combine the top-level organizational capacity of Boxes and the Box hierarchy with the issue-level organization of the Task hierarchy, and the variable choice of Modules, it should be easy to see how BigPicture could be customized to build a solution that fits your organization’s needs fairly well. Of course, with great flexibility comes great configuration setup time, so be realistic about whether your organization and teams will be able and willing to put in the time; paying for a highly flexible solution but not using that flexibility fully can be a waste of money.
BigPicture Server vs. Cloud
BP Cloud depends on the functionality and API of Jira Cloud, which do not offer everything Jira Server offers, so there are a number of relatively minor features lacking from BP Cloud. These include: in the Gantt box type’s Scope Module, the Detail View; the “status” field cannot be edited inline; there are no JQL hints as you type in Search Box and Quick filters.
Allows multiple management methodologies and frameworks (e.g. Waterfall and Agile) in the same context, rather than having to choose one for each project as in AR.
The ability to specify PTO including holidays and vacation time, which AR lacks.
XML and CSV exports are available, whereas AR only has CSV.
Comes with a REST API, which AR does not – though Jira does.
BigPicture Cons
The Kanban board is underdeveloped compared to the Scrum board; each type is equally well-developed in AR.
The estimated time in Jira issues is not pulled through, though Story points are.
Enterprise version
BigPicture Enterprise is an “expansion pack” that adds a handful of useful features onto BigPicture. Some of these additional features include: more preconfigured Box types since BP comes with only three (the additions include Agile project, Classic project, Hybrid project, Portfolio, Program, SAFe, and more), unlimited custom Box types, ability to relabel modules, unlimited scenarios per Box. Generally, we find that BigPicture Enterprise isn’t worth the additional cost, especially for teams who have a standard and consistent usage of Jira.
BigPicture vs BigPicture Enterprise
Big Picture Enterprise has additional features BigPicture does not offer, such as:
Additional stock Box types, including Portfolio, Waterfall project, Hybrid project, Agile project, along with the freedom to configure your own Box types
Tempo and Trello integration
Multi-level rollup (project up to a program)
View and report on multiple programs at once
Unlimited configuration
Configurable module names
Unlimited what-if scenarios
Read More
For more information on BigPicture, start with the app’s page in the Atlassian Marketplace, which contains links to BigPicture documentation and more.
Structure.Gantt
Structure is a Jira plugin that uses real-time issue data to easily visualize and track the status of multiple projects, across an entire portfolio. Within Structure, work can be grouped by and filtered on field values to organize information based on common themes or groupings.
The extension Structure.Gantt (“S.G”) – a separate product – provides additional modules and functions, including the Gantt and Resource views. S.G allows progress to be visualized through the use of Gantt charts by issue to identify potential problems or sticking points. The Resource module shows resource allocation by a user based on previously defined capacity metrics to help visualize resource capacity across the organization. Without S.G, Structure isn’t a viable alternative to Advanced Roadmaps for Jira.
Structure.Gantt enables new components: a Gantt chart and a Resource Planning view.
Scheduling: S.G charts allow either Automatic or Manual Scheduling. Automatic Scheduling uses the Project Start Date, Issue Durations, and Dependencies to determine how the issues should be scheduled in a waterfall. Manual Scheduling places issues on the Gantt chart based on their Due Date and Duration.
Resource Planning: Adds to the screen a list of users and a calendar view of their assigned work based on duration.
Key Concept: Structures
Structure is so named because one of the key features is a hierarchical arrangement of Jira issues in table format, called a ‘structure.’
Structures can be defined manually, or using preset choices like traditional agile hierarchy or issue status, or using dynamic generation mechanisms like JQL searches and boards. Each structure can be modified with grouping, filtering, and sorting, and can be extended to include child issues. Structures display as tables, with issues for rows and issue data for columns; in addition to Jira fields, column types include Progress, Totals, and Formula.
You can create a private version of a structure to play around with, and save a snapshot of that private version called a Perspective which you can share with other users or save as a bookmark for future use. Structures can also be grouped into folders for ease of organization and navigation.
Highlighted Features
Scaled Agile Implementation: scale more smoothly, by showing the essential information on any level, be it portfolio, program, or team.
Unlimited Hierarchy: The ability to automatically apply the issue hierarchy as defined in Jira. Users can also create their own hierarchies manually to align to personal preferences for issue layout within Structure.
Portfolio Views: Issues can be pulled from multiple or all projects within Structure, which provides the ability to visualize all important issues and milestones across the entire organization, in one place.
Pre-Set and Custom Templates: Save time and effort by creating Structures as templates for repeated use. Users can easily clone Structures to continue building on the base configuration for different purposes or views.
Visualize Relationships: View dependencies and issue linkages with visualized relationships. Create new dependencies or visualize those in existence with drag and drop functionality.
Aggregated Field Values: Sum up all time spent on issues in a project or in an Epic, useful for comparing high-level estimates with actual time logged.
Structure.Gantt vs. Advanced Roadmaps: Key Differences
Structure.Gantt Pros
Due date is calculated using task duration estimate and capacity, whereas Due Date is a separate field in AR. This is mostly a matter of preference.
Rest API available, which AR lacks.
Customizable calendar allows the ability to include workday exclusions to represent PTO; AR lacks support for PTO.
Structure.Gantt Cons
Due date is calculated using task duration estimate and capacity, whereas Due Date is a separate field in AR. This is mostly a matter of preference.
In order to use Gantt charts and engage in resource planning, you have to pay for the Structure.Gantt product, which costs as much as Structure. AR, of course, is an all-in-one solution.
Dependencies are displayed on an issue by issue basis, not by resource; AR can link projected capacity to demonstrate dependencies.
Capacity is tracked through issue status and issue related progress, not by individual or team resource; AR offers some ability to manage capacity on an individual level.
IE browser is not supported.
Structure Server/Data Center vs. Cloud
The Cloud version lacks a number of features present in the Server and Data Center versions, including:
The maximum structure size is limited to 10k rows.
Inline editing is not available for some fields.
Sharing of Perspectives is unavailable.
Users cannot search for structures by owner / permissions.
Issues from all projects are available to all structures.
All users with access to the app can create/edit structures.
For more information on Structure and Structure.Gannt, start with the Atlassian Marketplace’s pages for the app and for the extension, which contain links to documentation and more.
Tempo Planner
Tempo describes its Jira app this way: “Tempo Planner is a capacity and allocation tool, perfect for project teams with strict deadlines where resources are allocated based on availability, role, and more.” So that should give you a sense for where it focuses as a solution.
Tempo Planner (“TP”) is a more targeted product than the others we’re examining, focused on enabling users to allocate the time of resources against tasks and projects. Within that wheelhouse, it offers good flexibility and options. If you’re looking for additional functionality like managing Work Breakdown Structures or planning across a larger scale like a project or initiative, TP may not meet those needs. In fact, TP uses the word “plan” to refer to a timeline of work allocated for a resource, and NOT a larger scale assembly of those timelines for a project or initiative.
Note that if you’re already using Tempo Timesheets for Jira, you’ll get more out of Tempo Planner than if you’re using another solution for time tracking/reporting.
Most Common Use Cases
According to Tempo, its Planner product is used most often for these use cases:
Resource Capacity: Balancing workloads and understanding current resource allocation.
Estimate Need for New Projects: How many more new initiatives can you fit into your schedule, and does your team need more projects.
Allocate Resources: Assign resources to tasks based on roles, availability, or teams.
Measure Against Plan: Compare planned time to actual hours logged, with easy reporting to add/remove staffing (requires Tempo Timesheets).
Learn and Improve Efficiency: Look back at previous projects to better estimate future projects, including project profitability.
Highlighted Features
Plan multiple scenarios using actual hours pulled from Tempo Timesheets (if you use it).
Rest API available as well as export/import options to CSV and XML.
Schedule individuals and teams on a project, task, or ticket level. Allocate or request resources for high-impact initiatives while ensuring workloads are balanced and realistic.
Track the allocation of every team and user for weeks or months into the future.
Allow multiple users to plan time on the same issue, and filter any set of users you need.
Leverage various Resource Planning views to quickly see the current state of all projects and resources. Use the Capacity Report to effortlessly review several commitments at once and simplify progress monitoring.
Tempo Planner vs. Advanced Roadmaps: Key Differences
Tempo Planner Pros
Full, easy integration with Tempo Timesheets, which provides a number of advantages over Advanced Roadmaps, like planning with actual work hours vs. estimates.
Filters provided for resource search, resources listed with name, role and discipline; AR has capacity reports capacity by team, but not the individual resource (though there are partial workarounds).
Rest API available as well as export/import options to CSV and XML. AR only offers export as CSV, and no API.
Holidays and PTO included in resource capacity, which AR lacks.
Tempo Planner Cons
Lacks the ability to plan with issue hierarchies such as Work Breakdown Structures – planning is focused on allocating time to resources. Issue hierarchies can be created using links in Jira, and then the issues can be imported to create plans, but there’s no way to manipulate the structure in TP. AR, of course, being built in to Jira, gives you full access to issue hierarchies.
Limited ability to view cross project dependencies by resource; a partial solution is possible with filters and reports, whereas AR offers the ability to link projected capacity to demonstrate dependencies.
Changes to Jira issues made in a plan are not synced back to Jira.
No Gantt charting, which AR has built-in.
Tempo Planner Server vs. Cloud
The Server version has a number of features lacking in the Cloud version:
Members can be added to a Team using Jira groups.
Member permission roles can be added to a Team using Jira groups.
Staff members can be organized into roles, locations, working schedules, and holiday schemes.
Cloud has only Capacity Reports for teams, whereas Server can also report on staff capacity by role, user, location, program, account, and project.
Read More
For more information on Tempo Planner, start with the app’s page in the Atlassian Marketplace, which contains links to TP documentation and more.
Solution Comparison Table
Note: This table serves as an overview, but should not be relied on for purchasing decisions. Always identify your organization’s and team’s must-haves, and enlist expert assistance to determine for certain – and at the level of detail you need – whether a solution meets your needs.
Items
BigPicture
Advanced Roadmaps
Tempo Planner
Structure + Structure.Gantt
Modules
Roadmapping (planning)
√
√
Limited capacity for large-scale planning
√
Gantt chart
√
√
√
Resources
√
√
√
√
Teams
√
√
√
√
Work Breakdown Structure
√
√
√
Reporting
√
√
√
√
Hierarchies (Work Breakdown Structures)
Unlimited hierarchy depth
√
√
√
Configurable views
√
√
√
Filtering
√
√
√
Selected functionalities
Are portfolio-, program- and project-level plans (roadmaps) linked together?
√
√
Sync- and re-sync with Jira
√
N/A
√
What-if scenarios (sandbox before committing changes)
√
√
√
Track progress of projects/programs
√
√
√
JQL filters
√
√
√
Dependencies between issues
√
√
√
√
Milestones / Releases
√
√
Drag & drop tasks into plans
√
√
√
√
Resource planning
Skills
√
√
√
Story points
√
√
√
√
Capacity planning
√
√
√
√
Holiday plans
√
√
√
√
Vacation plans
√ by adding exceptions to team members
√ by adding exceptions to team members
√
√
Project management paradigms / methodologies
Project/program-level management
√
√
√
Agile (Scrum & Kanban)
√
√
√
Portfolio-level management
√
√
√
Mixed methodology teams (Scrum/Kanban)
√
√
Iterations (Scrum)
√
√
√
SAFe®
√
√
√
Waterfall
√
√
√
√
Import/export features
API
√
Jira has an API, but AR does not
√
√
Supported file types
Export to csv; import available through Jira
csv, xls, xlsx, pdf
(a) xls, printable page – with Structure for Jira
(b) pdf, svg – with Structure.Gantt
Sample features
No export or import to BigPicture is possible without paying for the extension BigTemplate.
Share a read-only link to a plan or embed an iframe.
Export/import plans from team timelines to csv files.
(a) You can download the structure that you see on the screen as an XLS file.
(b) You can produce a PDF or SVG file with your Gantt charts using configurable export.
Business data & Annual pricing
500 users
Bigpicture: $10,795 BigTemplate $3,745
$7705
$9020, Gannt.Structure $2655 = total $11,675
Jira Data Center, 100 users, Atlassian Marketplace
As you know, Jira’s Advanced Roadmaps features and capabilities are complex. But that doesn’t have to mean AR has to confusing for your business. Oxalis is an Atlassian Platinum Solution Partner, which means we can help guide you through these services and best determine the options for your business:
DevSecOps Security Best Practices
The DevOps software development model has become increasingly popular, but it doesn’t inherently lend itself to the level of security required these days. DevSecOps builds on the value of DevOps, preserving its throughput and stability while integrating security best practices.
At Oxalis, we frequently work with healthcare and government organizations, whether states, defense contractors, or the DOD directly. Sometimes we develop the software and other times we help our clients develop the software, but in both cases, we take security seriously in our software development processes. Security in software development doesn’t tend to excite many people outside the software security industry, so let’s be clear on why it is always important.
Table of Contents
Why You Should Prioritize Security
Threats have been increasing – from malware, bots, hackers, and more – and are hitting much more than just the largest targets. It’s not only the software products themselves that are the targets: recently there was a supply chain attack on Azure developers via malicious NPM packages. And since the goal of many attacks is simply to gain some form of access, even development-adjacent platforms such as documentation are targets, as we’ve written about in Confluence Remote Code Execution Vulnerability: Everything you need to know about it. With the conflict in Ukraine, the number of state actor attacks has also greatly increased.
For any given week we could provide another ten example headlines. The fact is that it doesn’t matter what your role is in software development – whether you are a developer, a tester, project manager, program manager, or product manager of software – software security is now part of your job. It can’t be outsourced to a security team at the 11th hour to give their final blessing. This article covers how you can include security as part of your full lifecycle without interrupting the developer experience.
DevOps Overview
DevSecOps builds on top of the foundation that the DevOps revolution has put in place, so you really need a common working understanding of DevOps. There is no central definition, but generally speaking, DevOps is a set of practices intended to enable an organization to release software updates more often without sacrificing quality. It accomplishes this by taking activities traditionally occurring toward the end of the development process and “shifting them left”, a reference to the fact that in a left-to-right process diagram, steps to the left occur sooner.
One major effort to pin down the principles driving DevOps comes from DORA, the DevOps Research, and Assessment team, which is a research program acquired by Google in 2018. DORA studied software teams that deliver the most value, fastest, and most consistently, to analyze practices those teams optimized. In 2018 the program identified four metrics, shown in the graphic above, that have been widely adopted as the standard for DevOps teams. The left side represents throughput – release frequency and the development team’s speed – while the right side represents stability – risk and failure management.
How often are you making new releases of your software or pushing new builds into production? In the classic enterprise environment, deployments may be monthly or quarterly, requiring significant processes to implement. In the DORA-based DevOps model, deployment is ongoing, with frequency measured in times per day; organizations leading in DevOps may deploy 100 times in a day. The benefits include improving time-to-value for customers, and reducing the risk from production failures because changes are smaller and easier to fix.
Time for Changes
In a monthly or quarterly release cadence, each release comes at the tail end of a three-month process, so if you are a developer who misses the scheduled cut-off date, your change has to wait for the next release. Conversely, in the rush to meet that cut-off date, you’re more likely to do poor-quality work. DORA’s metric prioritizes reducing the time from the first code commit to the time of code deployment. This enables faster bug fixing and greater responsiveness to changing user needs and external events, which makes your product more useful and valuable to users.
Change Failure Rate
Of course, the chief reason long development cycles exist is to reduce the risk of failures before moving into production. Greater throughput must therefore be accompanied by robust testing of all types that are relevant to the product, otherwise, you risk creating a failed engine. It’s also vital to carefully define what a failure is for your organization, teams, and products – that definition will drive employee behavior (in order to meet the desired metric), so if you make it too broad or too limiting, you can unwittingly encourage undesirable behavior. Increasing your deployment frequency can improve the change failure rate since it’s generally easier to test small changes than large ones.
Mean Time to Recovery
Inevitably, despite your best efforts, failures will occur in production. When they do, you’ll want to minimize the delay between a failure occurring and its resolution via a production change. Going back to the classic enterprise model, these large monthly or quarterly releases are often done during the night because if a failure occurs, the size of your changes actually makes recovery more complex and time-consuming – potentially involving activities such as a database backup reindex – so you have to worry about the failure affecting users for a lengthy period of time.
Well-implemented DevOps relies on designing systems for the fastest possible recovery, such as the blue-green deployment model, in which changes are deployed to a subset of your platform (the “green environment”), testing is done, then production traffic is gradually routed from the subset running the current version (the “blue environment”) to the green environment. If failure is detected after deployment, traffic can be easily routed back to the blue environment. Approaches such as these complete the DORA-driven picture by minimizing both the resources needed to recover from a failure and the impact of the failure.
Integrating Security into DevOps
Now we move on to what it means to add Security to the above foundation.
You want security at every stage of the process, to be something everyone concerns themselves with.
You want to shift it left so security is thought about early in the cycle.
You want to preserve DX and UX.
Traditional security tools, time-consuming to use and siloed in a separate security team, won’t suffice. One challenge with DevSecOps is that there’s no single tool or tool collection you can go out and buy that enables you to suddenly be “doing DevSecOps.” But in pursuing the goal of a culture of continuous security, there are tools you can use to integrate security measures at every step in the software lifecycle.
Continuous Security
Remember the 8-stage DevOps infinity model? Software is never developed and then just done – it’s a continuous process. You’re making production changes about as fast as developers are releasing code. So your security checks have to be baked into that process as inherently as code commits are, and baked into every one of the eight steps. This is only possible if everyone takes responsibility for security in the stages they participate in.
Full Lifecycle Security
From a planning standpoint, how do you design features that enhance and improve security? You need to think about the threats that a new feature brings to bear on your product, so you can mitigate it in the planning process rather than after it’s already been exploited – and even better, so you can give your developers real-time feedback on potential code issues even as they are writing code. You want to build in a secure manner, pulling in only components that are secure. You want to make sure that your code and your builds aren’t doing anything unexpected or untoward. You want to have confidence that what you build is what goes into production, and that what’s in production behaves as expected. And you want all this automated, with minimal human interaction.
To complete the loop, you want to have the information you’re collecting from your production environments to go right back into the planning process. This gives you a short feedback cycle as you continue to respond and iterate quickly. For those who are new to DevSecOps, and even to DevOps, the big wins come from the code deployment part of the chain, CI/CD steps 2-6. In the monitor and respond steps, traditional cybersecurity tools and approaches can be useful, but only to the extent, they’re integrated into the chain, so they can happen in real-time – rather than having to stop everything and wait for a separate team to do something.
Do Your Threat and Risk Assessments
Clearly, every organization is different, and every organization faces a different set of threats and has different concerns when it comes to security. Implementing security measures appropriate for a DevOps model, without sacrificing throughput or stability, is not trivial, and consulting experts is appropriate. There are a lot of standard tools and standard methodologies that can be applied. But it’s vital to ensure that any tools and processes chosen fit your needs well, including accommodating the particular industry space(s) you operate.
You need to do your own threat and risk assessments before any discussion of security tools. If you’re working in the government space, there are compliance and certifications that may dictate security requirements, such as static code analysis. You should be making choices for security without having compliance requirements. That’s definitely the Oxalis position on this. When we work with organizations, we start with such questions as What is the profile that you’re facing? Where’s your organization today? Where do you want to be based on what you’re doing? Where your concerns lie? The answers lead us to determine what will give you the best bang for your buck in the DevSecOps space.
The Foundation of DevSecOps
There are, however, two foundational pieces that are required for DevSecOps in all cases. The first, as mentioned earlier, is a culture of security, which underlies everything. While there’s certainly a role for dedicated security folks, DevSecOps requires security to be part of everyone’s job and of the entire organization’s culture. Product management, project management, coding, testing, deployment, network monitoring – everyone. The second part of the foundation is automating every possible action and then auditing the performance of that automation. Regardless of your role, ask yourself how to take a particular tool or tactic and automate it. Then whenever the automation runs, for good or bad, make sure that there’s a clear, indelible record of it. A fully-automated lifecycle can be a nightmare if you have no easy way of determining why it’s malfunctioning.
You can take these steps whether you’re just starting – maybe figuring outsource control and experimenting with some automated builds – or working in a mature enterprise environment. And without them, the following tools and tactics will be minimally useful.
DevSecOps security best practices: Three Areas of High Value
Let’s start talking about some actual tools and tactics that your organization can consider.
On your path to shift security to the left and increase speed, there are three major areas to focus on: auditing and controlling upstream risk and communicating that downstream, giving developers real-time tools and feedback so they know they’re writing code in a secure manner, and making sure that what you’re building is something you can trust in production.
Software Supply Chain
Software supply chain management is a hot topic at the moment. In December 2021, Oxalis spent a lot of time tracking and navigating the Log4j risk. Log4j, an almost ubiquitous Java component, has been around for decades before a major vulnerability was detected, with active exploits being run against it. Without functional software supply chain management, many organizations had no idea what their Log4j vulnerabilities were – which products had incorporated this component, or which internal tools or software used it.
Say I, as a software developer, don’t want to write my own tool to log errors because I know that’s a common component someone else has surely created. And there’s this great one called Log4j. It’s freely available, it’s in a Maven repository, so I just pull it into my code and start using it. And suddenly, I have introduced an unmanaged risk into the product – and into the company. No one else has any idea that component is being used, so no one else has a chance to anticipate problems or mitigate them if they happen.
In a DevSecOps environment, when I identify the need for a logging package and want to use Log4j, I poll my internal security repository. If Log4j is whitelisted, it gets pulled right in with no problem. Maybe it’s listed as iffy, so I can still add it, but the security team gets notified to inspect it. If it’s blacklisted, it just gets blocked. This approach does two key things.
It provides a clear point of audit since there’s a central repository of all external components used by our products and tools. And since we want to automate as much as possible, this repository can be used by a threat monitoring system that automatically notifies us of our risk points when a new vulnerability is discovered.
It prevents attacks such as the NPM supply chain attack of March 2022. When you’re pulling a library from a public repository, you might mistype the name of the library and not notice that there’s a package for that library – a bogus package containing a threat (this is called typosquatting). We want that library request to go through our security repository and be blocked.
So far we’ve been looking at the upstream side. Software BOM covers the same process downstream. You want to put together a list of every component that goes into a piece of software, and ensure it follows the software through the rest of the lifecycle. This will soon be required for federal contractors. There are plenty of tools for this, but they’re language-specific and rapidly evolving. If you have any questions about your specific case, get in touch with us, and we’ll help you navigate it.
Static Code Analysis
It’s exceedingly rare for an employee to intentionally introduce a security vulnerability. The major risk is accidental coding errors, such as the classic buffer overflow, in which (for example) the code implicitly assumes a particular list will be at most 10 items long. If an attacker finds a way to make an 11-item list, they’ll have broken into the system in some way, shape, or form. The common cross-site scripting attack often relies on code that fails to clean up user inputs, allowing characters that can be used for all sorts of harmful activity.
Static code analysis tools look for these types of errors (including, of course, far more sophisticated and subtle cases than buffer overflows) and provide real-time feedback to developers that they could be introducing security risk, as well as preventing that code from reaching production. These tools often use manual rules for identifying these errors, but are increasingly relying on AI and machine learning to identify those really subtle vulnerabilities that even a conscientious developer might not catch on their own.
Build Artifact Analysis
Now you’ve verified external dependencies and inspected your code for even subtle vulnerabilities. How do you check the results of the build to make sure they are what you expect to be flowing down into production? If you’re using a containerized application – taking what amounts to a VM image from the internet and putting it into your production environment – how can you be confident you’re not introducing some security vulnerability or an unpatched piece of software? Build artifact analysis relies on DAST tools to identify these risks, monitoring for unexpected external server traffic or unusual memory usage, or unauthorized file access.
Traditional Integrated CI/CD Pipeline
Now it’s time for a closer look at the test-to-deployment portion of the lifecycle, starting with the traditional CI/CD pipeline looks like after the developer develops their code and pushes it to, say, a Git repository. Some amount of automatic testing happens at a code level, unit testing happens here, and maybe there’s some basic code inspection. You then run the build and then deploy that piece of code – or maybe deploy the entire product into a testing environment where you run some integration tests. If all the testing passes, then you deploy to production.
All the security elements we’ve covered need to be integrated into the pipeline. When working on code, you should be receiving real-time feedback, not from the testing stage later on. Static code analysis and software supply chain management apply here – is the package you’re adding allowed? Am you at risk of introducing security vulnerabilities? Those same tools and tactics extend into your static testing phase, to check for vulnerable upstream packages and security code violations that you don’t want to get intoy our production environment. The build process is also where you develop your software BOM, to document everything that’s going into the build as an immutable record that follows the build all the way into production.
Build artifact analysis happens in two stages, starting at build time. Inspect your containers: are you pulling in containers that have, say, a version of SSH with an unpatched vulnerability or a bad root password set. Do your dynamic application testing: check for outbound connections, check unexpected file access, etc. You often do this in your testing environment. But your risk profile might dictate that you do this in a more isolated way, to maximize confidence that the application is behaving as expected and to minimize unexpected risks that might bite you when you go into production.
Sample DevSecOps Toolchain
There are, of course, many different tools that fit the scenarios mentioned here, and what’s right for your organization will vary. Here is a set we have found to work for a broad customer base, as a concrete example of what this all can look like. But your threat profile and risk profile, and the type of software you’re developing, where your organization is cultural – all dictate which products you’ll want.
This set of tools is flexible and fits a wide range of customer profiles as well as a variety of software development methodologies. It covers every part of the 8-step infinity model.
Confluence is an enterprise collaboration wiki with many fantastic features built-in for security planning, threat assessment, security incident response, and much more. A vibrant ecosystem of addons/plugins makes it easy to customize for your particular environment. DevSecOps, more than most models, requires everyone to be on the same page, so you need an accessible, robust, centralized knowledge management system.
Jira Software helps developers plan their work with structured security checks in place to ensure that testing has been done and passed appropriately. Jira Service Management makes sure any problems in production get attention from the right people – and are exposed to the development and planning teams, to factor into future work.
Bitbucket tracks who made which changes that got into production, with tight integration with Jira and Confluence.
Bamboo (on-prem) and Bitbucket Pipelines (SaaS) integrate with both Jira products, connecting code commits with build tracking with test reports with incident tickets. The result is that whether you’re a manager, developer, tester, or network monitor, you have access to all the data you need pertaining to a code change. Additional tools we use here include: Snyk, which does a whole suite of build inspections, and OSWAP Zed Attack Proxy, which wraps an internet proxy around your application, runs it, and looks for unexpected external communications.
Sonarqube provides static code analysis, including reports on error types, adherence to coding standards, unit tests, and more – and offers graphs of metrics history. This gives the real-time security feedback developers need and helps developers identify areas of improvement. It supports a large range of languages and development processes.
Nexus3 is an artifact management system that helps manage your software supply chain. It provides a firewall for software coming into your organization, a buffer between your systems and public software tool repositories. It actively polls vulnerabilities and will proactively notify you if there’s been a CVE announcement.
Oxalis has deployed this suite repeatedly for many customers, and helped train developers in it. We value it not just for its flexibility, but because it can be deployed on-prem, in your server closet, in your VMWare cluster, on Azure or AWS both in commercial space and in sovereign high-compliance spaces such as AWS Gov Cloud. In addition, these solutions are all available as SaaS-managed solutions, if your risk profile supports using a third-party managed solution. We’ve deployed this stack to all those scenarios – and we use it internally as well.
How to Get Startedwith DevSecOps Security Best Practices
1) The core of everything you do. Using Sonarqube to crank out error messages does you no good if you can’t figure out which developer wrote the code generating the messages so you can catch it earlier in the future. If it’s not happening automatically, it’s probably not happening at all or is consuming huge resources on it and it’s probably slower too. So again, you want to move fast, with frequent code deployments. 2) Understand this and align it with what you want to do on a roadmap basis. We can provide guidance and support on this. We don’t want anyone to add static code analysis just to check a box. It needs to be a specific response to your analysis of your organization’s security risks and concerns. 3) Break down silos. Get security out of the tail end just before release, and into the planning, early development, and architecture stages. You want security at each step in the lifecycle so that if one step fails, the next can catch it and prevent customer impact.
You develop your own software, and Oxalis helps companies who develop software with their work management tools. We’re excited to discuss this with you and hear about your concerns. Even if you’re just getting started on your DevOps journey or taking your first steps into CI/CD, we can provide guidance.
Recommended blog postsabout DevSecOps security best practices
Do you have questions about DevSecOps Security best practices?
Jira Buyer’s Version Comparison Guide: Which Do I Need? | Jira pricing, features and more.
Atlassian’s website provides a fair amount of information about Jira, and its popular issue tracking, service management, and project management software offerings.
This Jira Comparison Guide will explain the cost and features of each Jira product, and provide guidance on choosing the Cloud vs. Data Center versions. With all the available information, it can be hard to compare all the Jira pricing, factors, and what they can do for your business. Our Jira Comparison Guide aims to distill the most important information into one place.
For example, Atlassian has separate pages for the three main products, Jira Work Management, Jira Software, and Jira Service Management. Here, we’ll explain everything in detail (including Jira license cost per user). And then, there are yet again separate pages for the two hosting versions, Cloud and Data Center. Note that Atlassian no longer sells Server Edition, and if you want to stay self-hosted you will be subject to a minimum user tier or 500 on Data Center. Oh, and not all the products and features are available in the Data Center version that your business may need for extra levels of security or work management capabilities. Licensing costs for Jira are likewise scattered.
We’ll put it all together for you in this Jira Comparison Guide, so it’ll be clear which Jira options your business needs.
3 Factors That Tell You Which Version of Jira to Buy
There are the three key factors to consider:
Product: Jira Work Management, Jira Software, and/or Jira Service Management
Deployment: Cloud or Data Center
Note: Jira Work Management does NOT have a Data Center version.
Licenses: number and type
Update: Atlassian Announced End of Life for Server Edition Products
On October 16, 2020 Atlassian announced they were sunsetting their Server edition support by February 2024, and would halt the sale and service of their Server licenses by February 2021. This announcement supports the company’s recent moves toward simplifying their self-managed options and doubling down on their Cloud support for Jira Software, Jira Work Management, Jira Service Management, and Confluence. With this announcement, they also announced pricing changes for Cloud and Data Center licenses by February 2021.
What This Means for You
All of the information in this Jira Comparison Guide is still accurate, such as Jira cost per user, features and more.
We strongly encourage any companies adopting Jira’s suite of high power Agile software tooling to consider Cloud licensing, if possible.
If your company is unable to move to the Cloud for compliance reasons, Data Center products are available.
We broke down Atlassian’s announcement and offered suggestions and steps forward on our blog.
Jira Work Management, Jira Software, and Jira Service Management
These three products are independent, and can be used individually or partnered together. Atlassian recognized the crossover use of Jira for all business units. Marketing teams to HR functions started using Jira to track work and collaborate. The launch of Jira Work Management reflects the fact that its business project functionality is at the core of what Jira does, and is present in the Software and Service Management versions as well. So, if you want just Jira Software, you can use it without feeling the need to add other products. Here’s an overview of the products:
[table id=1 /]
The target uses listed above should give you a general sense of each product’s focus. Keep in mind: Jira is inherently flexible and extensible, not just by virtue of the hundreds of add-ons available in the Atlassian Marketplace. Its well-documented Java API allows anyone to write custom code and even create add-ons. So even if your use cases don’t clearly match what’s listed, Jira may still meet your needs. We have included some examples below for reference.
The fact that Jira offers a dedicated software version does not mean it’s necessary for software development. In fact, if you’re part of a small team or not following the Agile Development Approach, Jira Software could be more than you or your team needs. The fields utilized in Jira Software are built into both Jira Work Management or Jira Service Management for software development. It would be possible to build more simplistic configurations on those two products.
Jira Service Management stands separate from Jira Work Management and Software, as they have the self-service customer portal. The portal provides a simple external interface to Jira that allows unlicensed users to create requests and check on the status of their requests. Add-ons and customization can expand the actions available through a portal.
Note the key phrase “unlicensed users.” In Jira Service Management, a license is only required to work on an issue. This allows the flexibility to allow for many more people to use Jira than you could otherwise afford.
Business Cases
To illustrate Jira’s flexibility and extensibility, here are two examples of business processes that can be built in Jira:
1) Document Review
Say you’re a complex fabrication company that uses an engineering company to produce drawings and schematics needed to fill orders. Each document has to be reviewed both by you and the customer, and can go through several revision cycles before being approved and sent to production.
With Jira Service Management, you can create an external portal that engineers use to submit documents (including both attachments and metadata), while the customer uses it to review them. In Jira, your team receives a document request and reviews it, then uses a custom workflow to send the request to the customer for review via the portal. The customer sends the request back with their feedback, you review it again, send it to the engineer to revise. Eventually, the request is approved, and the workflow automatically routes it to production and the work begins. The engineers and the customer can do all that through the portal.
2) Marketing Collaboration
In this scenario, you have multiple teams working together on a large marketing campaign for the business. This campaign brings together many disciplines from content creation, copywriting, design, and development. Your teams need to collaborate and time their work efficiently to hit a deadline for an impending product launch. To date, you’ve been trying to string this together with tools oriented around those various disciplines and you’re even struggling to align to a product release from the software team.
With Jira Work Management, you can handle the entire process, from logging the work across all the teams to managing related assets for the campaign. You even have visibility across all the timelines and work for each team using Atlassian Advanced Roadmaps capability. And finally the icing on the cake: you can track your campaign and link it to an upcoming release while tracking the live progress with Advanced Roadmaps for the entire release. Now that’s work management across teams.
Bottom line: Jira Software is a perfect fit if you’re doing Agile Software Development with a sizable team or multiple teams.
Is there a special case we didn’t cover? We’d love to learn about it. Contact us and we’ll find a solution that fits your team needs.
This choice should be familiar with many other software offerings, such as Microsoft SharePoint.
[table id=2 /]
Here are some practical questions to consider:
Will you have the resources to handle your own installation and maintenance?
If not, Jira Cloud is best.
Will you need full redundancy, high availability, or other enterprise-level architecture features?
If so, Jira Data Center is best.*
Will you have the resources for custom development?
If not, Jira Cloud is best.
Do you have government security requirements to meet, e.g. NIST or ITAR?
If so, Jira Data Center is best.*
Is it easier for your company to pay larger amounts of money annually, or smaller amounts monthly?
If monthly, then Jira Cloud is best, as it’s the only option that has a monthly plan.
*Oxalis recommends Data Center licenses only to those companies that have heightened security and compliance needs. Otherwise, we recommend going Atlassian Cloud.
What Are the Differences between Jira Cloud Licenses?
Wondering about Jira license cost? Atlassian sells its Cloud licenses with different tiers depending on your required features: Cloud Free, Cloud Standard, Cloud Premium, and Cloud Enterprise.
Jira Work Management, as a lighter version of the more robust Jira Software, only offers Cloud Free and Cloud Standard licenses. There are few differences between the two, however, the differences essentially separate daily users from casual users. Find out more at Atlassian here.
Jira Work ManagementPricing
[table id=11 /]
Cloud Free
Atlassian’s Cloud Free version for Jira Work Management is great for businesses that are interested in checking Jira out as a whole, without committing fully. They offer a great collection of features; in fact, a company could use Cloud Free license for Jira Work Management up until they need more users. At that point, the value should be demonstrated and therefore the cost justified.
The Jira Work Management Cloud Free license does impose restrictions on storage, user count, and administrative tools like audit logs and advanced permissions.
Cloud Standard
The Cloud Standard version of Jira Work Management can be summarized by saying Jira Work Management Professional. The way Atlassian built their feature structure, businesses will need up upgrade to Jira Work Management Cloud Standard once they grow their user base or need more storage (250GB to be exact). Another real benefit is adding customer support, which is available to Jira Work Management Cloud Standard users between 9 am and 5 pm. Support will help with configuration, pulling reports, and configuring/customizing layout.
If you’re finding that Jira Work Management does not have all of the features that your business needs, consider making the leap to Jira Software.
*Note: Jira Pricing, scales with the number of users – the more users, the more affordable per-user cost. Contact us for an accurate Jira pricing.
Jira Software Cloud Free
The Cloud Free tier includes most of the dynamic features that sets Atlassian’s flagship products apart from the competition. Users have access to scrum and kanban boards, as well as Agile reporting, Roadmaps, and Automation (which most project management tools charge for).
However, the Cloud Free tier of Jira Software falls short with support, permissions, and storage. The 2GB of included storage can fill up relatively quickly depending on usage. Atlassian does provide a robust Community Support system, but many customization questions require more in-depth conversations and workshopping. If your company needs to separate viewing permissions within the company or with internal vs external users, the higher tier will suit you well.
All in all, the free tier is invaluable for those debating whether to make the Jira Software switch. There are several factors that, with adopted use, will all but require a paid tier.
Cloud Standard
The Jira Software Cloud Standard tier is the next step up for Jira Software or Jira Work Management users ready to unlock the full power of Jira. As an administrator, you have access to a bevy of new features including Advanced Permissions, Project Roles, Audit Logs, and 250GB of storage (rather than 2GB at the Cloud Free tier). Since you can have up to 10,000 users (starting at $7 per user per month for the lowest tiers), this tier can meet the needs of many organizations for years.
Jira Software Cloud Premium
If you’re using Jira Software as your company’s hub, Jira Software Cloud Premium is well worth the cost. With this tier, admins obtain access to insights, sandboxing, release tracking, and unlimited storage – and it has Advanced Roadmaps for Jira included – the robust planning and forecasting Atlassian app that we use extensively at Oxalis.
Cloud Premium is double the price per user of Cloud Standard, but Atlassian makes up for it with all of the aforementioned included features. Not to mention, Atlassian also includes 24/7 priority support for Cloud Premium users.
The bottom line: if Jira Software is your company’s central hub, Cloud Premium will help you save money and time down the road as your processes improve and become more trackable.
Cloud Enterprise
Jira Software Cloud Enterprise is the highest tier available. With unlimited storage, 24/7 enterprise support, Atlassian Access, and unlimited sites included (the other tiers only allow for one site), Cloud Enterprise has you covered.
Companies should only consider Cloud Enterprise if they require those higher-level management and security requirements. Atlassian Access, Atlassian’s enterprise-wide subscription for enhanced security and centralized administration for Atlassian cloud products, brings an extremely high level of security to Jira Software. Features like SAML single sign-on (SSO), User provisioning (SCIM), Active Directory sync, Organization audit log, Organization insights, and Enforced 2FA are bundled into Atlassian Access.
You can add Access to the other tiers if needed, but you’ll have to purchase it separately.
While pricing isn’t readily available for Cloud Enterprise, Oxalis is able to pull a quote for your needs. Contact us and we will get the process started for you.
*Note: Jira Pricing scales with the number of users – the more users, the more affordable per-user cost. Contact us for an accurate pricing.
Cloud Free
Atlassian provides Jira Service Management Cloud Free so teams can see for themselves what JSM has to offer at a high level. It includes most of the robust features that help users understand how JSM works, especially if they are testing JSM vs. competitors like Zendesk or Freshdesk.
There are, of course, limitations to the free tier. For example, JSM Major Incidents (Incidents that cause significant disruption to everyday business operations) are capped at 5 per month, which can be extremely limiting for anything larger than a small, local business. Postmortems (a process of evaluating incidents after they’ve been resolved), a cornerstone for a successful Agile framework, are also capped at 5 per month.
Cloud Standard
With JSM Cloud Standard, you can get up to 5,000 agents (paying less per user as you scale up) with 250GB of storage, and the Cloud Support Team ready to help you during local business hours. Cloud Standard users are allowed up to 100 major incidents per month (quite the jump from 5), with more auditing and reporting features available.
Cloud Standard is the typical entry point for companies adopting JSM for their ITSM needs. It includes enough to cover the most common needs and run your ITSM operations. If you find yourself needing even more, there’s Cloud Premium.
Cloud Premium
Cloud Premium is for those medium to large businesses that use Jira Service Management for their entire ITSM operation. This is the tier that unlocks unlimited major incidents, postmortem, and storage. Customer support at the Cloud Premium level is also 24/7 premium support.
This tier also includes newer tools like Sandbox, which allows agents to test and control updates before rolling them out across the entire system. As with the other Jira tools, Cloud Premium offers higher levels of admin and reporting tools.
One major feature Cloud Premium gives you is the Incident Command Center, where you command, control, and coordinate incident response, and effectively collaborate through Opsgenie-hosted video bridge and other integrated communication tools. Admins can investigate incidents and monitor the health of their system with these tools, enabling faster incident management and system improvement.
Cloud Enterprise
As with Jira Software, Cloud Enterprise for Jira Service Management includes the highest level of reporting and administration controls, with unlimited storage and 24/7 enterprise support. As with Jira Software Cloud Enterprise, Atlassian Access is included with JSM Cloud Enterprise—leading to extremely high levels of security for those large enterprises that require it.
Jira pricing and Atlassian products prices are based on specific enterprise needs, so if you’re interested contact us and we will work with you to pull the best quote for your needs.
Jira License Types
Jira Work Management and Jira Software are licensed per user, meaning that a user cannot use the system unless a license is purchased and assigned. As mentioned above, Service Management only requires a license for those who need to work issues in Jira, called “agents“. It’s worth noting that licenses for agents are more expensive than licenses for Work Management and Software users—not surprising since there are fewer of them.
Jira Cloud license types may be paid monthly or annually. Cloud licenses will expire if you fail to renew when required. Data Center licenses are only available annually, but they do offer a 50% discount for academic clients.
Larger customers will want to engage a partner for best pricing and license optimizations.
All three products offer an affordable starter option for small groups (meaning up to 10 users or 3 agents). Beyond that, volume discounts make larger numbers of licenses progressively cheaper.
One practical consideration for Jira Service Management: it includes the business process features in Jira Work Management. If you’re setting up projects in Service Management that do not use the extra features of Service Management, but only the business process features, you still have to pay for agent licenses. As a result, it may be cheaper to get both Work Management and Service Management to save the expensive agent licenses.
Jira pricing sound confusing? Let’s chat and talk through what configuration will work best for your team.
Licensing Cost Overview and Comparison
To translate Jira’s license per user costs into more practical terms, we’ve picked some sample numbers of users to compare costs between products and deployment options.
Monthly Cloud License Comparison
Here are samples of the licensing costs per month for the Cloud version of each product.
Note:All costs are in US dollars.
[table id=3 /]
Annual Cloud License Comparison
Since the Jira Cloud version also offers a discounted annual subscription plan, it’s worth comparing the annualized monthly cost for each product to the corresponding subscription cost. Here is a breakdown of the cost per year for Jira products.
[table id=4 /]
This table shows how much businesses can save with the subscription plan. But do the math for the number of licenses you actually need, as there are some beneficial points in the Jira cost per user hierarchy that might not be apparent from the surface. You can find Atlassian’s pricing calculator here: Jira Work Management | Jira Software | Jira Service Management.
Jira Comparison Guide conclusion: Jira cost, Jira features, where to go from here?
In some cases, the information provided above will be enough to determine which Jira product(s) and deployment options are the best fit for you and Jira cost per user. But most companies, especially larger ones, have plenty of business processes that don’t clearly fall into those categories. And the truth is, we all know that reading the marketing materials doesn’t always provide the most accurate reflection of performance. This is where we come in. Oxalis can bridge that information gap, and help you figure out whether Jira products and Jira pricing, can meet your particular needs.
We covered many of the benefits and drawbacks of, and differences between, Jira Work Management, Jira Service Management, and Jira Software over the course of this post. However, if you need more information while deciding if the Jira Suite is right for you, send our team of experts a message—don’t let lack of information make your decision for you. Need special help about Atlassian Jira Subscription? Send us a message.
For more information or help with Jira training, we offer Jira consulting services to help with best practices in configuration, customization, and more. If you still have questions after reading this Jira Comparison Guide, let us know.
Used by Google Analytics 4 to persist session state and track usage across visits. The XXXXXXXXXX portion corresponds to the Oxalis Google Analytics property ID.
1 year
_gac_
Contains information related to marketing campaigns of the user. These are shared with Google AdWords / Google Ads when the Google Ads and Google Analytics accounts are linked together.
90 days
__utma
ID used to identify users and sessions
2 years after last activity
__utmt
Used to monitor number of Google Analytics server requests
10 minutes
__utmb
Used to distinguish new sessions and visits. This cookie is set when the GA.js javascript library is loaded and there is no existing __utmb cookie. The cookie is updated every time data is sent to the Google Analytics server.
30 minutes after last activity
__utmc
Used only with old Urchin versions of Google Analytics and not with GA.js. Was used to distinguish between new sessions and visits at the end of a session.
End of session (browser)
__utmz
Contains information about the traffic source or campaign that directed user to the website. The cookie is set when the GA.js javascript is loaded and updated when data is sent to the Google Anaytics server
6 months after last activity
__utmv
Contains custom information set by the web developer via the _setCustomVar method in Google Analytics. This cookie is updated every time new data is sent to the Google Analytics server.
2 years after last activity
__utmx
Used to determine whether a user is included in an A / B or Multivariate test.
18 months
_ga
ID used to identify users
2 years
_gali
Used by Google Analytics to determine which links on a page are being clicked
30 seconds
_ga_
ID used to identify users
2 years
_gid
ID used to identify users for 24 hours after last activity
24 hours
_gat
Used to monitor number of Google Analytics server requests when using Google Tag Manager
1 minute
Marketing cookies are used to follow visitors to websites. The intention is to show ads that are relevant and engaging to the individual user.
