High-performing agile teams do not just deliver work, they reflect on it. That habit of stopping after every sprint to ask what went well, what did not, and what should we change is the heartbeat of continuous improvement, or kaizen: small, steady adjustments that compound sprint after sprint. But a good retrospective needs good evidence, not just gut feeling. As we continue investing in agile ways of working, we want to give you a look at where we are headed with agile reporting: the sprint reports, charts, dashboards, and insights that give teams the evidence their retrospectives need to actually drive that improvement.
Quick navigation:
- Co-creation with our community
- Making retrospectives less painful
- Sprint reports
- Sprint goal and work package overview
- Burndown chart
- Burnup chart
- Velocity chart
- Epic progress chart
- Created vs. resolved chart
- Cumulative flow diagrams
- Sprint scope changes
- Cycle time and lead time
- Reports across sprints and portfolios
- Individualization
- Direction we’re exploring for agile reports
Co-creation with our community
Over the past months, we have talked to teams running Scrum, Kanban, and SAFe at scale, and we dug into where reporting falls short, especially for teams coming from tools like Jira, where reports often feel scattered across plugins. Those conversations shaped the direction below. As always, this is a preview of concepts and early prototypes, not a finished feature set, and we are sharing it early because we want your feedback to further improve it.
Making retrospectives less painful
The goal of the new reporting concept is simple: make it effortless to see how a sprint actually went, without exporting data into a spreadsheet or stitching together three different plugins. Reports should answer the questions every retrospective starts with: did we finish what we planned, where did work pile up, how did the sprint scope change, are we getting faster or slower, without anyone having to build that picture by hand.
Sprint reports
At the center of the new concept sits the sprint report: a single view summarizing what was planned, what was completed, what was added mid-sprint, and what got carried over. Instead of digging through a board’s history, a team can open one page after the sprint ends and immediately see the shape of what happened, a natural starting point for any retrospective. All that of course including the visual charts you need to quickly recognize the areas which went well or which might need some attention. Of course you will also have the possibility to check out the reports during the sprint in order to recognize problems early.
Sprint goal and work package overview
Your sprint report will open with a sprint goal, so that the focus area is clear to everyone. You will also get an overview over sprint health, showing the overall sprint progress and scope changes.
Burndown chart
The classic burndown chart is getting a refresh. It will track remaining work, in story points, hours, or number of work packages, against the sprint timeline, so teams can see at a glance whether they are on pace, ahead, or falling behind. We are also looking at making the ideal progress guideline easier to compare against actual progress, so deviations, both scope increase and decrease, are obvious.
Burnup chart
For teams whose scope shifts mid-sprint, which, let’s be honest, is most teams, we are planning to introduce burnup charts alongside burndown. Rather than only showing what’s left, a burnup chart plots completed work and total scope over time, making scope creep visible instead of something you only notice in hindsight.
Velocity chart
To help teams plan future sprints with more confidence, velocity charts will show completed story points, work packages, or spent time across recent sprints. This isn’t about chasing a bigger number every time. It’s about giving teams a realistic, data-backed sense of their own throughput so sprint planning stops being a guessing game and you can have a reliable foundation to plan a healthy sprint scope.
Epic progress chart
For teams tracking work at a higher level than individual sprints, we are planning an epic progress chart, a view that shows how many work packages or story points have been completed or are still open within an epic. Rather than clicking into an epic to manually tally status, a team or stakeholder can see progress across one epic, or several epics side by side, at a glance. This is especially useful for teams working across multiple sprints or product increments, where an epic can span weeks or months and no single sprint report tells the whole story.
Created vs. resolved chart
For teams juggling a steady stream of incoming work, support tickets, bugs, unplanned requests, we are planning a created vs. resolved chart. Plotting new work against resolved work over time makes it easy to spot whether a backlog is shrinking, holding steady, or quietly growing out of control.
Cumulative flow diagrams
For teams working in Kanban or a Scrumban flow, the cumulative flow diagram will visualize how work packages move through each status over time. Widening bands point straight to bottlenecks. If “in progress” keeps ballooning, that’s exactly where a team should be looking.
Sprint scope changes
With the integrated work package tables you can quickly get an overview over all work packages which were completed within a sprint and which not. Also the scope increase and decrease will be listed in detail.
Cycle time and lead time
We are also planning to include cycle time and lead time to the reporting possibilities, two related but distinct measures of speed.
Cycle time tracks how long a work package takes once someone actually starts on it, showing how fast the team moves once work is picked up.
Lead time tracks the full journey, from the moment a request first enters the backlog to the moment it’s done, reflecting how long the requester has actually been waiting.
The gap between the two tells its own story: a large difference usually points to a queuing or prioritization problem rather than a speed problem, since most of the delay happens before anyone even starts the work. Teams will be able to configure which statuses mark the start and end of each measurement, then see both metrics together so retrospectives can address the right problem instead of guessing at it.
Reports across sprints and portfolios
For organizations running multiple teams, particularly under SAFe, we are exploring reports that roll up across sprints, projects, or an entire portfolio. Rather than checking six team boards individually, a program lead could see a single combined epic progress or cumulative flow view spanning every team in a Product Increment.
Individualization
For the first release of agile reporting we are planning to offer a static sprint report page. In further iterations we will give you a possibility to adjust the default sprint reports, so that you can choose only the charts which are relevant to your team. We are also planning to extend the project dashboards, offering the agile charts as configurable dashboard widgets.
Direction we’re exploring for agile reports
These concepts are our vision for agile reporting within OpenProject. Thank you to everyone who took part in user interviews and contributed to this vision. We’d love hearing your feedback on the prototypes we are publishing here, so that we can further improve the reporting capabilities based on your needs.
These prototypes represent where we want reporting in OpenProject to go, closer to how retrospectives actually work, and useful to teams practicing Scrum, Kanban, or SAFe. We are planning to release the first iteration of agile reports pretty soon, so stay tuned.
