Three honest ways to get a number out of Jira, and where each one stops. Written for the person who has to recommend one of them.
| Question | Built-in gadgets | Export to a spreadsheet | This app |
|---|---|---|---|
| Sum a numeric field (story points, estimate, cost) | No — they count issues | Yes | Yes, any numeric field |
| Group by the Team field | No | Yes | Yes, plus sprints, components, versions and your custom fields |
| Two fields at once, with row and column totals | Only for a few predefined fields | Yes, as a pivot table | Yes, any two of your fields |
| Stays current without anyone touching it | Yes | No — it is a snapshot from the day it was exported | Yes, recalculated every time the dashboard loads |
| Respects each viewer's Jira permissions | Yes | No — the file shows whatever the exporter could see | Yes, calculated as the person looking |
| Data leaves Atlassian | Never | Yes, onto a laptop or a drive | Never — runs on Atlassian Forge, stores nothing of its own |
| Historical reports (velocity, time in status, cumulative flow) | Some, in the agile boards | If you build it | No, and not planned |
| Cost | Included | Free, plus somebody's hour every week | Free up to 10 users, then a subscription through Atlassian |
Stating this up front saves everyone a trial:
A note for consultants. If you standardise reporting for a client, the parts that usually matter are these: one read-only scope (read:jira-work), no vendor infrastructure and no egress, every calculation performed with the viewer's own permissions, and configuration that a project manager can do without JQL. Write to apps@probiusproiect.ro and we will walk through it with you — twenty technical minutes, no sales call.