Getting started with Crosstab
Crosstab is a Jira dashboard gadget. You pick two things to break your issues down by, and one numeric field to add up, and it draws the table: a total in every cell, and row, column and grand totals that reconcile with each other.
Jira's own Two Dimensional Filter Statistics gadget answers how many. This one answers how much — and when it could not read everything it was asked to, it says so on the grid rather than quietly drawing a smaller number.
Adding it to a dashboard
- Open the dashboard you want it on, and choose Add gadget.
- Search for Crosstab. It is in the list under that name.
- Choose Add gadget, then Edit on the new gadget to configure it.
The gadget does nothing until it is configured, and it says so rather than drawing an empty table.
The four choices
The form asks four questions, in this order.
Where the issues come from. Either a saved filter — chosen from the filters you can already see — or a search of my own, which is a line of JQL you write. Both are read with your own permissions, not with anybody else's: the grid a colleague sees from the same gadget is the grid their permissions allow.
Down the side and Across the top. The two axes. Anything the site offers that is not about a person: issue type, status, priority, project, component, label, sprint, epic, a select field of your own, team.
Add up. The numeric field whose total fills each cell — story points, an estimate, a time field, any numeric custom field on the site. If the site has none, the form says that rather than offering an empty list.
The three settings under them
And where that is empty, read … — a fallback chain. Where an issue carries no value in the field above, read this one instead, and the next one after that. A board half-migrated from one estimate field to another is the ordinary case, and without this it reads as half-empty.
Leave out work that is finished. Finished issues are excluded from the read. Worth knowing before you turn it on: Jira answers the count of what it skipped with a figure it calls approximate, and the grid says so — it is the only number in this gadget not counted from the issues themselves.
Also count: Epics · Sub-tasks. Off by default, because an epic carrying the sum of its children and the children themselves both counted is the same work counted twice.
Reading the grid
Four views, switched at the top of the gadget:
| View | What each cell holds |
|---|---|
| Total | The sum of the chosen field |
| % of row | That cell as a share of its row's total |
| Issues | How many issues are in the cell |
| No value | How many issues in the cell carry no figure at all |
The fourth is the one to look at before quoting any of the others. A total drawn over a board where a third of the issues are unestimated is not wrong, but it is not the whole board either, and this view is where that shows. Mark what is missing does the same thing on the totals view, shading the cells whose figure rests on issues that carried nothing.
Under the grid, How this grid was read, and what it leaves out prints the whole provenance: where the issues came from, how many were read, what was skipped and why. It is the paragraph to paste into a meeting alongside the number.
Keeping a grid
Keep this stores the figures as they are now, so that a number quoted in a meeting can be defended six months later when the issues behind it have moved.
What is stored is this app's own totals and the four choices that produced them. Not a copy of your issues: no issue keys, and no field values beyond the labels already drawn on the axes. It goes into your own site's app storage and does not leave it.
A kept grid can be compared against today's, and the difference is drawn in place.
Exporting
Export offers three: Copy puts the table on the clipboard ready to paste into a spreadsheet, Download CSV and Download Excel write a file. The Excel workbook carries the No value view as its own sheet, and every export carries the same provenance paragraph the screen shows — including, in capitals, a warning across the top when the read was cut short.
Saved setups
A named set of the four choices, saved once and started from again on the next gadget. Setups are visible to the whole installation rather than to you alone, and the form says so where the search is typed — a JQL line can name a person, and a line you write is a line your colleagues can read.
What it will not do, on purpose
No axis can be a person. Not assignee, not reporter, not creator, not any user field on the site. A total broken down by a person is a metric about that person, and that is not what this gadget is for. The rule is checked against the schema of every field your site returns, rather than against a list of field names.
No background jobs and no external host. The gadget reads when the dashboard loads, and it reads nothing but your own site. There is nothing to whitelist and nothing scheduled.
No deep configuration. Four choices and three settings. That is not a roadmap gap, it is what keeps the app supportable by one person.
When something cannot be read
Every refusal says which of the two it was — the filter or the issues — and what would fix it: somebody to ask for a share, an administrator to grant a scope, or simply a wait when Jira asks the gadget to slow down. A read that ran out of time draws what it got and marks the totals partial rather than presenting them as complete.
Each of those states tells you it will try again the next time the dashboard loads, and the gadget's own menu carries Refresh for trying sooner.
Removing it
Remove the gadget from the dashboard the way you would any other. Kept grids and saved setups live in the site's app storage rather than in the gadget, so they survive a removed gadget and go with the app when an administrator uninstalls it.