Jira calculated fields: is the native field enough?

Summary

• A Jira calculated field helps project managers make better-informed decisions on better data, e.g. task prioritization using RICE scoring and keeping track of labor costs.
• The native Jira formula field is a great tool for combining and calculating Jira field values on the same work item.
• If you want project-wide insights, i.e. calculations spanning multiple work items, native Jira won’t help you.
• Another limitation is that the native formula field can’t pull values from select lists, only number or free text fields.
• If you need to calculate Jira custom fields using values from dropdowns and multiple work items, one way is to export your field data and do the calculations externally. But that means your data lives in two places.
• Another way of doing advanced calculations is with Jira automation. But Jira automation is not for the faint of heart! And there are limits on how many calculations you can do per month.
• An Atlassian Marketplace app like Awesome Custom Fields lets you do advanced cross-work-item calculations using values from select lists. It also lets you display the value of your calculated field as a custom visual, and comes with a range of other custom field types for enhanced project management and visual appeal on tickets.

There’s good news and bad news

People need Jira calculated fields for forecasting project timelines, rolling up costs and time across multiple work items, calculating prioritization scores, and making better project management decisions.

The good news? In 2026, Atlassian introduced a built-in Jira calculated field for Jira and Jira Service Management. For years users had to build complex automation rules, pull their data out of Jira, or augment their Jira with an Atlassian Marketplace app. Now teams can configure dynamic calculated fields directly within Jira work items without heavy admin overhead, automation maintenance, or additional licensing costs.

The bad news? Jira’s formula field is only good for doing calculations on a single work item. If you want to calculate Jira fields across multiple work items, well… you still have to build complex automation rules, pull your data out of Jira, or augment your Jira with an Atlassian Marketplace app.

This article explores your options for calculating Jira field values if your mathematical needs exceed the scope of the native field.

What is a Jira calculated field?

A Jira calculated field is a custom field where instead of the user inputting a value, the value is calculated and inputted for you. The value is calculated based on other Jira fields; so you enter 6 in one field and 2 in another, and the Jira calculated field multiplies the two and inputs a value of 12. And a Jira calculated field is dynamic, so if you change the fields it’s calculating, it will automatically recalculate and update the value.

Historically there was no built-in Jira calculated field. Now Jira ships with a formula field that lets you add, subtract, multiply, and divide number fields or integers. It can return averages, percentages, minimums, maximums, powers, and absolute values. It also offers conditional logic, allowing users to create formulas that adapt based on the values of other fields.

A formula field was one of the most sought-after Jira custom fields ever. Teams have pined after simple calculations directly on work items since Jira was born. Things like ratings, cost estimates, impact scoring, and KPIs. The sort of data you really want living in Jira, not a disparate spreadsheet.

So formula fields in Jira give many teams exactly what they need: a quick, lightweight improvement that stops them from having to do mental math and manually input a figure.

Why you might need a more complex Jira calculated field

Native formula fields are a massive step forwards, but Jira teams have a habit of turning simple calculations into, shall we say, ambitious ones. Particularly when calculations become part of planning, prioritization, and reporting.

So you might start with, “Add these two fields together.” Later it becomes, “Actually, one of those values comes from a dropdown, B should include all the subtasks, ignore anything that’s already in ‘Done’, and roll up the total to the epic.” We’ve all been there. 😄

Unfortunately, you’ll soon hit a wall with the native field. This is for two main reasons, which I’ll explore now.

1. No dropdown values

The native Jira calculated field can’t currently reference values from a single-select or multi-select list in formula logic. This is a problem if you rely on fixed values for estimation, prioritization, or other scoring models.

Say you want to generate a “RICE score”, where “RICE” represents Reach, Impact, Confidence, and Effort, each of which is a numerical value. When all the fields are populated, the calculation (Reach × Impact × Confidence) ÷ Effort is triggered, and the score is written into a RICE score custom field.

The built-in formula field could only calculate this if the numerical values come from a number or free text field. But this means the values are manually typed by the user and can be any number under the sun. RICE values will have a set scale, e.g. 5, 10, 15, 20. Number fields are only appropriate for values that constantly change or can’t be predicted. If someone types “7”, well, that’s just not very helpful, is it? It’s why a select list, which only allows fixed options, is necessary for this sort of calculation.

2. Calculating Jira custom fields across multiple work items

A project manager overseeing a release, campaign, or major feature will often need to aggregate values from multiple Jira work items for the purposes of forecasting, resource planning, and progress tracking. This is beyond the scope of the native formula field, which doesn’t support cross-work-item rollups.

For example, you may want to calculate the effort left on an epic by adding the remaining estimates of all child work items. Or total the cost of a release by combining the estimated hours of all its stories and multiplying them by the relevant team rates.

The native field can only calculate a value using an epic’s own fields. It can’t sum the story points, remaining estimates, or costs of all its child issues. This gives the field limited applicability for project-level reporting and decision-making.

Taking Jira calculations beyond single-ticket formulas

Although the built-in field is great for making decisions on individual tasks, it’s not so good for a project manager looking at the bigger picture.

So if you need to calculate Jira custom fields using values from dropdowns and multiple work items, you have three main options:

1. Do it outside of Jira
2. Use a Jira automation workaround
3. Use an Atlassian Marketplace app

Let’s take each of these in turn.

Option 1: Export your data

You could export your Jira data to a tool like Microsoft Excel and do the calculations there. You can export to Excel out of the box, but it’s cumbersome and limited and you have to set up your calculations once your field values are in the spreadsheet.

You’d be better off using an app like Better Excel Exporter for Jira, which calculates custom field values automatically during the export process.

Not ideal, though. These are calculated fields in Excel, not Jira. And Better Excel Exporter will only calculate the fields when you export. So if your source values change, your calculated values won’t update unless you run the export again and create a new file. It’s not a dynamic process, and that’s what users want.

Option 2: Jira automation workaround

Jira automation keeps your data in Jira and lets you go much further than the native Jira formula field.

Using the Lookup work items action, smart values, and math expressions, you can calculate field values across multiple work items. And you can calculate values selected from dropdown lists and even aggregate those values across related work items.

But setting up these calculations is time-consuming and easy to get wrong. It requires a good understanding of smart values, branching, and automation troubleshooting when rules break. It also means that your formula logic is tied up in automation flows rather than in a more editable and maintainable custom field.

Another problem is that there are limits on how many times Jira automation rules can be executed per month. On the Free and Standard Jira plans, there’s a limit of 100 executions and 1,700 executions respectively. On the Premium plan, there’s a limit of 1,000 executions per user. Therefore, if you need to do a lot of calculations regularly on your Jira tickets, Jira automation may not be the answer.

Ultimately, this method of calculating Jira custom fields is called a workaround for a reason. Ideally, a Jira calculated custom field should look and function like any other Jira field, which the new built-in formula field does. It just doesn’t do everything some users need.

Option 3: the advanced formula field from Awesome Custom Fields (ACF)

To avoid the rigmarole and uncertainty that comes with exporting data to external tools or configuring Jira automation rules, you’ll need an app from the Atlassian Marketplace.

There are several apps dedicated to running advanced calculations in Jira. The problem is it’s all they do. Installing a whole app just to calculate some Jira fields is something many users are reluctant to do. Now that the problem has been partially alleviated by native formula fields, it can be even harder to justify.

An app like Awesome Custom Fields is a different proposition. This app adds a wide range of flexible custom fields to your Jira. These enhance project management and visualization on Jira work items, and allow you to overcome a number of native Jira limitations.

One of those limitations is the ability to perform calculations using select field values and data from multiple work items. The advanced formula field that comes with Awesome Custom Fields supports both. It uses Jira expressions to create formulas, but if you’re new to Jira expressions, the built-in autocomplete function will help. Simply type issue. to see a list of available fields and select the ones you want to reference.

Jira calculations you can do with Awesome Custom Fields

With ACF’s advanced formula field, you can perform the calculations we mentioned earlier.

RICE scoring

To calculate a RICE score pulling values from select lists, you can use the following Jira expressions in your field:

1
let reach = Number(issue.customfield_10101.value);
2
let impact = Number(issue.customfield_10102.value);
3
let confidence = Number(issue.customfield_10103.value);
4
let effort = Number(issue.customfield_10104.value);
5
(reach * impact * confidence) / effort

So value. is the selected option and Number() casts it to a number, i.e. the numbers you have set for your RICE scale. The custom field IDs are only examples; in the real field, the autocomplete suggests them after you type issue..

Remaining effort on a Jira epic

To calculate the effort left on an epic by adding the remaining estimates of all child work items, you could use the following Jira expressions:

1
issue.childIssues
2
    .map(child => child.remainingEstimate == null ? 0 : child.remainingEstimate)
3
    .reduce((total, estimate) => total + estimate, 0) / 3600

Because remainingEstimate returns seconds, we use / 3600 to convert to hours. The .map() expression guards against child items without an estimate.

Note that childIssues works for both company-managed and team-managed spaces (issue.stories only exists on classic epics).

You could also do the same calculation but ignore items that are already “Done” with the following Jira expressions:

1
issue.childIssues
2
    .filter(child => child.status.name != "Done")
3
    .map(child => child.remainingEstimate == null ? 0 : child.remainingEstimate)
4
    .reduce((total, estimate) => total + estimate, 0) / 3600

Total cost of a release

This calculation combines the two capabilities of ACF’s advanced formula field, i.e. it’s a cross-work-item rollup using select-list values.

The calculation totals the cost of a release by combining the estimated hours of all its stories and multiplying them by the relevant hourly rates.

1
issue.childIssues
2
    .filter(child => child.customfield_10105 != null && child.remainingEstimate != null)
3
    .map(child => (child.remainingEstimate / 3600) * Number(child.customfield_10105.value))
4
    .reduce((total, cost) => total + cost, 0)

The customfield_10105 stands for a single-select hourly rate field on each child work item, with numeric option labels, e.g. 100, 150, 200. For every child work item that has both a rate and a remaining estimate, the expression converts the estimate to hours, multiplies it by the selected rate, then adds everything up.

The .filter() skips children where either value is missing, so incomplete items don’t break the calculation.

It’s essentially the same pattern as before, just with select-list access — Number(child.customfield_X.value) moved inside the per-child .map().

A visual advantage of ACF’s advanced formula field

Another advantage the advanced formula field has over native Jira formula fields is the ability to display the calculation as a visual. The native field only displays a raw value, but Awesome Custom Fields lets you render the number as a colored badge that’s more readable and commands more attention.

For example, if you’re using a calculation to prioritize tasks, you could use classic RAG colors to highlight the ones that should be worked on first. Values below 250 can be green (least urgent), values between 250 and 750 can be amber, and values above 750 can be red (most urgent). This makes it clear how important the work item is as soon as you open it.

Awesome Custom Fields vs dedicated advanced formula apps

The main benefit of ACF over dedicated advanced formula apps is that you get a whole bunch of other custom field types as well. These include:

T-shirt sizes for estimating tasks, featuring visual icons of T-shirts

Multi-level cascading select list for capturing more detailed category information on tickets

MoSCoW field for prioritizing tasks with colored cards

Progress bar for visually representing work completion

Color labels for customizing Jira label colors

These custom fields build on Jira’s standard fields, making work items more visually appealing and better at communicating key information. They also enhance your project management capabilities by introducing field types for status, estimation, and prioritization that aren’t available out of the box.

If you want to know more about calculating Jira custom fields using ACF’s advanced formula field, watch our video.

If you want advanced Jira calculated fields that help you understand the health of your projects, not just individual work items, try Awesome Custom Fields for Jira free for 30 days.