Sprint status report stakeholders actually read (made in Jira, PDF-ready). What would you change?

[Alex Lutterbach]

I’m a fan of Jira, but I hate the weekly manual reporting loop for clients and leadership: pulling the right issues, copy/pasting into a separate doc, formatting, and sending.

I built a way to generate a sprint report directly in Jira in a few clicks. It’s PDF-ready and gives two levels of detail: a quick overview (so stakeholders can skim) and a detailed list of issues grouped by status.

Now my stakeholders get something useful, and I’m not spending time manually creating updates every week.

For transparency, I built this for my own workflow and I’m actively iterating. I’d love input on what you think a stakeholder-ready sprint report should include. If it helps, I can share a sample output screenshot in the comments.

Questions:

1. If your sprint update could only include 3 things for stakeholders, what would they be?

2. Where does your update live today: slides, Confluence, email, or something else?

3. What’s the one part you still have to manually add every week (risks, decisions needed, dependencies, narrative, owners, etc.)?

[Aron Gombas _Midori_]

This is interesting! Or, on a broader scope, keeping external people up-to-date with easy to understand, C-level type summaries is definitely an interesting use case.

If you implemented your solution using Jira dashboards, then you can use the PDF Automation app to export the dashboard to PDF and email it to your stakeholders, periodically and automatically using standard Jira automation rules. It can make the process require even less manual work.

[Alexey Pavlenko _App Developer_]

Hi @Alex Lutterbach

Sure, please share, it would be great to hear your experience. Probably, it would allow me to know how to approach something from a different angle than I am used to.

Personally, I invested a lot of time into teaching stakeholders how to use JIRA, read dashboards and understand engineering. After this effort, I almost always was able to decrease the number of check-in meetings and interactions with stakeholders while maintaining the same or even a better level of alignment with them. Most of the time, they could learn everything in real time from dashboard(s) instead of asking the same questions. Planning and demo sessions became real planning and demo sessions where they could ask ~half of their questions. Stakeholders became more attentive knowing that there are no more number of another meetings instead.

Answers:

1. Completed vs Incomplete scope, Added and Removed scope after the sprint started.

I used a real-time dashboard with metrics. Eventually I developed a dedicated app for that, which became the backbone of the dashboard.

2. Initially they lived in all the places you listed, after my optimizations - JIRA Dashboard. The app can render the past sprint states allowing to conduct any discussions or retrospectives.

3. Only minutes of meetings were stored in Confluence. Everything else I managed to store on the JIRA dashboard

Best regards,
Alexey