Why are we still making Jira reporting so hard?
I speak to hundreds of engineering and product leaders each year. And the ones that use Jira for project management as their issue tracker (these are numerous) have all kinds of approaches to reporting.
But the common denominator is that very few of them really feel they’re nailing reporting for their Jira instance. Maybe, if you’re here, you feel the same way.
Jira’s native reporting
There are numerous reports available in Jira. We’ve got four categories of reports – Agile reports for both Kanban and Scrum teams, forecast and management reports, and issue analysis.
For example, Scrum teams have access to a range of charts, such as burndown charts, sprint reports and velocity reports, that they can use to evaluate real-time project progress and performance.
But there are three big, common reasons why they let the side down, from a practical perspective.
- Limited functionality. The built-in reports are sometimes less of a one-size-fits-all and more of a one-size-fits-none.
- Time-consuming to use in practice. You don’t get a nice, neat dashboard with the stuff that matters to you and your team. Instead, you have to go and generate each individual report and compile it yourself. That’s a big job to do on a weekly or fortnightly basis.
- Little context. Sure, you get your graph (or whatever it might be), but you’ll have to add context and commentary yourself, or chase your team members for updates, taking them out of their flow and taking up everyone’s time.
- Permission scoping. It makes some sense to take a permission-based approach, but when it comes to reports, in practice, it means different people see different reports.
I’d say a surprising number of businesses still lean on the built-in Jira reporting though. That is often either because they are reasonably small – I’m talking start-ups, scale-ups and SMBs – or simple force of habit, and being practically, psychologically and loyally invested in the Jira ecosystem.
Several Jira add-ons, or extensions, are available to augment the Jira reporting experience. Some certainly improve the experience (look at Arsenale Dataplane, Report Builder and Custom Charts in the Atlassian marketplace) – but they still make our lives hard in other ways. We’ll get onto this soon.
Big BI tools
A hefty proportion of our Jira-using community is getting better custom reporting using an external BI tool. Incumbents take up the bulk of the market share you’ll have heard of, like Tableau, Power BI, Google Big Query and so on.
There’s plenty good about this.
- Configurability. Jira native reports are the way they are, and can’t really be changed. When you do it all yourself, you can have whatever you want, if you have the time and resources to build it.
- Far more powerful crunching. These tools’ abilities are much more advanced than Jira’s native stuff, and you can do what you want with historical data, too.
- Total integration. Whatever you want to integrate as data sources, you can, if you have the resource and data quality.
But they still come with a trade-off I want to talk about.
I recently spoke to the CEO of a small business who had hired an in-house data technician to maintain Tableau. It was obvious talking to them that it shouldn’t have been necessary. This story is more or less repeated with businesses of all sizes, who need disproportionate resources to power the data they think they need, vs the value they actually get.
On the one hand, all of these BI tools come with a range of hefty price tags, and I’m not just talking about the money.
- Setup cost. Even smaller businesses with simpler requirements will generally need to front significant resources to get what they need set up. That might need to come from an in-house team, or be outsourced.
- Report creation cost. A dashboard isn’t a full report until it has context and commentary. And in most cases, it takes humans time to do this. They might chase people for updates, and then present it during a (time-consuming) meeting, or create a written report which commentates on the dashboard. Or, they might skip this step altogether and have just the metrics and charts, always up-to-date but never with the commentary that is needed for them to be really effective.
- Maintenance cost. Your tool setup likely evolves regularly, rather than being static over periods of time. You might also need to update integrations or data handling when the way you use the tools of your data sources changes.
On the other hand, by nature, the dashboards teams set up usually aren’t able to deliver the full picture. They innately lack data storytelling.
Reports created even by the most full-bodied BI tools innately lack context and commentary.
We think this is normal. Our BI tools provide a hollow framework for discussion. They tell us that velocity has improved, but they don’t tell us why. They tell us that a Jira project is stalling, but they don’t tell us what’s happening next.
Without this context, there’s little value in decision-making. With the context, it’s tedious and time-consuming. Both contrast sharply with Agile's focus on efficiency and value. Report creation, being a non-revenue-generating activity, incurs significant costs. For example, if a lead engineer earning $100,000 annually spends 3 hours weekly on reports, the direct cost is $8,108 annually, not including benefits and overheads. The opportunity cost is even higher. Considering that an engineer is expected to generate 3 to 5 times their cost in ROI, every hour spent on reporting could mean a loss of $156-260 in potential revenue, totalling an opportunity cost of $32,432. This means the annual cost of report generation can exceed $40,000.
So we’d better make it count, or eliminate the cost.
We need to stick these metrics, charts and Jira data together in a meaningful way. We need data + context + commentary.
Doing it manually
When we decide to get our data, context and commentary manually, our job is to make the process as painless as possible and the output as impactful as possible, while accepting the ongoing costs we talked about above.
We have to justify the cost.
I think about Data + Context + Commentary like this:
- Data – Operate ‘Lean Reporting’. Your core report should be stripped to the metrics and charts that are impactful.
- Context – Every part of the report is in the context of your projects and goals. In other words, it’s strategically relevant.
- Commentary – You’ve got data storytelling in plain language. No matter who is reading, they understand what’s going on.
Reports also need:
- Concision – They can be scanned in under 20 seconds.
- Clarity – The key information is prominent. They’re clearly actionable.
Creating context-rich reports is a slam-dunk use case for the new generation of advanced AI.
Now there’s a way to solve the trade-off and have both ease of report creation, and quality and actionability, without the costs.
It’s called Stepsize AI. Now, Jira dashboards build themselves.
Stepsize AI monitors activities in your Jira software. It uses this to craft concise, actionable weekly reports brimming with the ideal blend of context and detail.
Every week, these reports highlight key metrics through easy-to-scan graphs and insights, enriched with crucial context and commentary.
- Metrics with automatic commentary. Metrics without commentary are meaningless. The AI does your data storytelling for you.
- Progress at a glance. Understand the flow of progress with rich, actionable graphs and insights, with sources so you can investigate if you need to.
- Project-level AI insights. The AI uses your epic structures and its own intelligent classifications to identify themes among all your loose tasks.
- Security first. You’re in control of your data, and it’s never used to train AI.
All this means you effectively have instant insights, with zero-setup, and complete visibility so you can get aligned on what matters.
I'm eager to hear your thoughts.