It's 2024. We can do better than Jira sprint reports

I speak to dozens – hundreds, really – of engineering leaders about collaboration, alignment and reporting.

And it seems to be something that, almost universally, teams struggle to get quite right.

Today, I’m writing about a topic that comes up all the time – sprint reporting in Jira. 

I think the reason I have this conversation so much is that sprint reporting belongs to a family of activities which only exist because alignment isn’t the natural state for groups of humans.

My colleague wrote about this alignment problem in some detail over here, but in brief, the more organisations grow, the more complex it becomes, and the harder alignment is to maintain.

So, we rely on classic methods to try and attain alignment. We use synchronous methods, like daily stand-ups and team meetings; asynchronous methods like asking people to update us and sharing reports; and our systems of record like Jira, Linear, GitHub and so forth.

The problem is, most of us never really attain alignment – it’s more like we mimic it. Humans aren’t wired for alignment.

Sprint reporting is one of these classic methods we use to get everyone in scrum teams on the same page.

In the absence of obvious alternatives, the majority of teams who use Jira to manage Agile sprints do one of two things:

• Use native Jira sprint reports
• Compile their own reports manually

The Jira Sprint Report

If you’re reading this, there’s a reasonable chance you’re already entirely familiar with sprint reporting in Jira.

But for the uninitiated, here’s a quick look.

The Jira Sprint Report is a relatively simple report from their range of reports which you can generate for Scrum boards, via Projects > Reports > Sprint Report.

Just like any other sprint reporting, it’s designed to support the team retrospective or progress checks.

Their sprint reports show::

• Burndown summary (the red line represents actual work completed, while the grey line is a guideline drawn from the total estimate)
• Opsgenie alerts (for helpdesk management – not really a Jira software thing)
• Status report – a summary of completed issues and incomplete issues, along with the issue type, priority, status and story points

In Jira Sprint Reports, you can change the sprint, but not the value – it measures progress via story points. If you don’t use story points, you’re out of luck.

Jira has other reports, such as the Burndown Chart report (the chart in the Sprint Report is basically taken from this)

The real problem with Jira’s Sprint Reports

Talking about the limitations of Jira’s Sprint Reports could be a big old topic.

The main win for the Sprint Report tool is pure convenience – it’s already built into Jira, it’s right there, ready to use.

If you’re already familiar with them, you’ll be familiar with some of its practical limitations too. They include having limited detail, only supporting story points, only showing burndown with no ability to understand things like project allocation or velocity, relying on issue-level summary and more. There are more, but they miss the point.

But the really big problem with the tool is more fundamental:

Jira Sprint Reports don’t surface the insights that actually matter.

Why? Well, there are two parts to this, one more practical, and one more foundational and intrinsic.

First – it lacks crucial features. The sprint reporting tool simply doesn’t contain some of the features we should expect to have in a good sprint report. Among these features, I include things like velocity insights, project allocation, completion rates by project and an explanation of the sprint goal. Jira has a range of other reports, but compiling them in one place takes time.

Second – everyone has to read between the lines. Or, to put it another way, commentary is entirely DIY. The Sprint Report tool effectively gives you raw (or close to raw) data. It’s unable to do anything smarter than that.

These are simple problems, but they have consequences.

Here are some of the consequences I end up talking to leaders about most…

• Plain inefficiency. When reports don’t surface what matters, there’s more time spent reading between the lines, and they’ll likely arrive at slightly different conclusions, often without realising. This, in turn, costs more time.
• Less clarity and focus. When agile reports aren’t clearly linked to strategic goals, it’s harder to be focussed on what’s going to move the needle. Lack of project-by-project qualitative insight hampers our ability to strategise and allocate our resources effectively.
• Misinterpretation. The rawer the data, the more susceptible it is to being misunderstood – or indeed, interpreted in different – maybe unhelpful – ways.
• Accountability. Creating and assessing accountability is harder when data isn’t uniformly interpreted. And it’s harder to do that against the strategic goals and delivery goals when they aren’t on the report in the first place.
• Slower, poorer decisions. Simply put, when we can’t see what’s going wrong, we can’t take steps to rectify it. Conversely, when it’s not clear what’s going right, we can’t understand what’s causing thing to go right and do more of it.

So, what instead?

Jira Sprint Reports are a simple, out-of-the-box solution. But Jira is a generalist multi-purpose tool. And it’s common for generalist, multi-purpose tools to have somewhat ordinary features for specific purposes.

The obvious route is to supplement the Jira Sprint Report.

If this is the case, someone needs to be responsible for doing that. They’ll need to be sure they’re keeping on top of sprint goals, provide project context to the raw-ish data that comes out of Jira and supplement the report with missing data, like project allocation and velocity. 

For example, Jira’s Velocity Chart can be generated and extracted via their reporting tool and added to the report. Jira’s chart won’t have any additional context, so the person will have to provide it.

But today, there’s a better route.

With my team, I’m building an advanced AI tool that creates perfect sprint reports, every time.

It’s called Stepsize AI.

Stepsize AI observes everything happening on your Jira board. It develops context about your projects and goals, and forms connections between tasks, activities and more.

The result is super accurate, automatic weekly sprint reports with the perfect amount of context and detail.

And, without you having to do any trawling through issues or generating multiple reports full of raw data, it’ll…

• Show you the data you need along with useful commentary
• Give spooky accurate summaries of your progress on your sub-projects
• Bring everything back to your goals
• …And give you links to sources, so you can find out more if needed.

‍

‍I’d love to chat about how you think about reporting, and get your feedback on our sprint reports.

If you want to check out Stepsize AI, you can head here. You can even generate your first report for free.