One team finishes its sprint on Friday. Another is still waiting for an API change before it can test its part of the release. Both Jira boards are up to date, and neither team has reported anything incorrectly. But the release involves seven teams, not two. There are dependencies from the last planning session that haven’t been resolved, plus several new features that weren’t part of the original scope. The program director has to work out what all of this means for the delivery date. Meanwhile, the steering committee still has the old schedule.
Closed ticket counts won’t answer every question that comes up during a program review. The team waiting on that API change might have very little work left, but it can’t finish until somebody else delivers. There is also the work added after PI Planning, which wasn’t included in the original commitments. We’ve selected seven Jira reporting and planning products that deal with these situations in different ways. When comparing them, three areas deserve attention:
- Progress across teams: Can the tool show how several teams are moving toward a shared release, rather than displaying separate sprint results;
- Dependencies and scope: Does it show blocked work, changes to the backlog, and commitments that have shifted since planning;
- Reports for management: What information can a program lead bring into a delivery review without collecting figures from several boards by hand?
A dependency board might show exactly which API task is holding up testing. A delivery report could show that the release scope grew by another twenty issues. Those are different pieces of the same release discussion.
1. Easy Agile Programs and the Dependencies Between Teams
Easy Agile Programs is a Jira application for coordinating work and planning across several Agile teams.
During PI Planning, one team schedules a feature that depends on another team’s work. Both teams may be satisfied with their individual sprint plans even though the dependent tasks are scheduled in the wrong order. Easy Agile Programs uses shared planning views to expose these relationships before they become delivery problems.
After planning finishes, dependencies may change, objectives need tracking, and new blockers can affect work already scheduled for an increment. The application provides reports for dependencies and PI objectives, along with Delivery Insights for reviewing flow measurements across teams. Delivery Insights is available for Jira Cloud. Not every function works identically across all editions.
A program board needs to remain useful after the planning event. Cross-team relationships can change as work progresses, and project leads need a record of those changes. The following planning and reporting views support that need:
- Dependency reports: Linked Jira issues reveal blocked work and scheduling conflicts between teams;
- PI Objectives: Teams can track objectives associated with the current increment;
- Delivery Insights: A consolidated view of cycle time, throughput, and work in progress across participating teams.
A dependency remains unresolved after its planned sprint. The program lead inspects the linked issues and identifies the teams involved before the next planning discussion.
2. Broken Build and the Numbers Behind Shared Delivery
Broken Build develops Agile Reports & Gadgets, a multi-team reporting application for Jira.
A program director needs to report on eight Jira teams working toward one delivery commitment. The sprint summaries arrive on Friday, one from each of the eight teams. Some show a healthy amount of completed work, but the release backlog has changed since those sprints began. Agile Reports & Gadgets can bring the selected boards into the same report, making it possible to check the outstanding work without reconciling eight separate totals.
The teams may still be closing issues at much the same rate as before. Meanwhile, new tickets have been added to the release since the last review. The forecast changes, and the program lead needs to check which additions were included in the latest scope. A program manager needs to examine scope movement alongside historical delivery data. Monte Carlo forecasting uses that historical data to estimate completion ranges, and the previous article already covered probability levels in detail.
Different reporting questions require different measurements. A sprint commitment report cannot replace cycle time analysis, while a burnup chart answers questions that an issue count doesn’t. Broken Build provides several reporting views based on Jira work, each suited to a specific question. The application does not force every problem into one chart type. Views available include:
- Board sets: Pick several Jira boards and keep that selection for other reports. There’s no need to choose the same five teams again for every chart;
- Flow data: Throughput shows how many items were finished, while cycle time and WIP give a closer look at completion times and unfinished work;
- Changes to the backlog: New issues can push a release further out even when work is getting done. Burnup, burndown, and sprint reports help track those changes;
- Forecast dates: Monte Carlo uses past delivery data to estimate when the remaining work might be finished. The results include different confidence levels, not a promised deadline.
A program director reviews a changing release date before a steering committee meeting. The added scope and outstanding work matter more than the application itself.
3. Kendis During Program Increment Execution
Kendis connects PI Planning and delivery tracking with Jira.
The program board might look settled right after PI Planning. The feature is still on the PI board, but its sprint has changed. Another team is waiting for an integration task, and a few unplanned items are now mixed into the backlog. The updates are in Jira, spread across the teams doing the work. Kendis synchronizes Jira information with its program board, where the RTE can check features and dependencies without opening every team’s board separately.
Two features may both appear as in progress, even though one was part of the original PI plan and the other was added last week. A feature may have changed status three times since planning, or the scope may have grown without anyone formally revisiting the original commitment. Kendis has reporting options for looking back at these changes, including PI progress and risks that haven’t been resolved.
Before the weekly ART sync, an RTE can check which features moved and whether the dependencies discussed last week are still open. The original PI plan matters here, since the current state alone won’t show everything that changed. Kendis provides several ways to examine that information:
- Program boards: Show features and dependencies across the teams participating in an increment;
- Scope changes: Track work added, removed, or adjusted after the initial PI plan;
- Objectives and risks: Follow PI objectives, dependencies, and risks recorded through the ROAM process.
One dependency might already be resolved, while the feature waiting on it remains scheduled for a later sprint. The RTE can check the linked work before discussing the next steps with both teams.
4. Structure PPM by Tempo
Structure PPM by Tempo lets Jira users organize issues from different projects into custom portfolio hierarchies.
A feature belongs to one initiative, but the work behind it is spread across three Jira projects. Some tasks sit under separate epics, and the teams involved don’t even use the same board. For the portfolio manager, opening those projects one by one isn’t particularly helpful. Structure PPM allows the issues to be arranged under the initiative they contribute to, without moving them out of their original Jira projects.
Four epics sit under one initiative in Structure PPM, although their tasks belong to different Jira projects. The teams keep updating those tasks as usual. In the portfolio view, the analyst can open an epic to see its underlying work or collapse the hierarchy to compare estimates without going through every issue. The initiative-level figure is calculated from the work included below it. Which values count toward that number depends on the columns and rules configured for the report.
That gives the reporting team a few things to work with when preparing a portfolio view:
- Issue organization: Related Jira items from separate projects can appear under the same initiative without moving them between projects;
- Rollup values: Estimates and other numerical fields can be added up through the hierarchy, using the configured aggregation rules;
- Calculated columns: Formulas allow reports to use Jira field values and information from other levels of the structure;
- Different report layouts: Columns, filters, and grouping can be changed without rebuilding the underlying Jira projects.
The initiative total is higher this week, but the teams haven’t created any new tasks. An existing epic was placed under that initiative yesterday, bringing its issues into the calculation. The analyst checks the parent relationship and the formula used for the total.
5. Agile Hive for SAFe Reporting Inside Jira
Agile Hive adds SAFe planning and reporting views to Jira.
A feature can sit in progress for most of a PI, even though the teams involved keep closing tickets. Their boards show what’s happening in individual sprints. The RTE has a different problem: figuring out which pieces of the feature are still unfinished and where they belong in the ART plan. Agile Hive keeps Jira work organized around SAFe structures, with team activities linked to features and PI objectives.
The development tasks are done, but integration hasn’t started. Another team was supposed to deliver a service needed for testing, and that work is still open. On the original team’s board, there’s little left to discuss. The feature itself remains unfinished. Its dependency is recorded elsewhere in Jira, with the next PI review approaching.
A SAFe program review may require information organized by ART, objective, and feature rather than only by Jira project. Those relationships need to remain visible after PI Planning. Relevant parts of Agile Hive’s reporting setup include:
- SAFe hierarchy: The connection between team work, features, ARTs, and higher-level planning structures;
- PI reporting: Tracking PI objectives and their associated delivery work;
- Risk and dependency visibility: Cross-team relationships and risks appear in program planning and reporting views.
An ART review shows a feature remains unfinished because of work owned by another team. The relationship would be examined through the program structure.
6. BigPicture by Appfire: When Project Schedules Collide
BigPicture connects Jira projects with portfolio planning, resource allocation, and risk tracking.
November’s resource plan has one awkward detail. The QA team is booked for two releases during the same week. One project expects regression testing to finish by Thursday, while the other has acceptance tests starting on Wednesday. Neither schedule looked particularly ambitious on its own. BigPicture by Appfire lets portfolio managers check these allocations alongside Jira tasks, project timelines, and milestones linked to other work.
The two projects aren’t even planned the same way. Engineering uses two-week sprints, but the second project has fixed approval dates and a separate handover process. BigPicture supports Agile, traditional, and hybrid planning, so the schedules can sit within one portfolio without following identical workflows. Friday’s approval meeting is already on the calendar. The people expected to prepare the test results are still assigned to the first release.
Resource conflicts are only part of what needs checking. A project may still be on schedule while one of its dependencies has slipped. Budgeted work and available capacity can also tell different stories. BigPicture provides several views for examining these situations:
- Portfolio oversight: Track project and program progress without opening every plan separately;
- Linked schedules: Examine dependencies between tasks and milestones, including work managed under different projects;
- Resource allocation: Review how teams and available capacity are distributed across planned activities;
- Risk records: Keep project and portfolio risks visible alongside the work they may affect.
There isn’t enough QA capacity for both testing windows. Moving one project’s deadline is an option, but first the manager needs to check which tasks depend on those dates. Some testing could move to the following sprint. The integration tests might not have that flexibility.
7. Atlassian Align and the Work Behind Portfolio Targets
Atlassian Align, previously known as Jira Align, is a separate enterprise planning platform that works with Jira.
A company has approved a major initiative, but the actual work is scattered across several programs. Some of it appears in Jira as epics, some as smaller tasks, and different teams have their own delivery schedules. Atlassian Align connects that work with the initiative it belongs to. The portfolio view isn’t limited to what individual teams have finished during a sprint.
A leadership report might show the initiative as on track, even though one of its planned features has moved into the next quarter. That doesn’t automatically mean the report is wrong. The portfolio status and the feature schedule describe different levels of work. Align allows those levels to be examined together, including the objectives attached to the initiative and the delivery work recorded in Jira.
Following an initiative from the original strategic goal down to current delivery work is difficult. Reports prepared for different organizational levels may contain different information. Elements of Align’s enterprise reporting approach include:
- From objectives to Jira work: Align shows which features and initiatives are tied to a business goal, including work handled by different delivery teams;
- Portfolio details: A program may appear on schedule while some dependencies remain open. Managers can examine those records alongside progress figures and reported risks;
- Enterprise Insights: Align data can be exported for analysis in Power BI or Tableau, where it can be combined with reports from other business systems.
An executive asks which initiatives contributed to a strategic objective during the quarter. The information would need to be examined at portfolio and delivery levels.
Final Thoughts
A missed release date doesn’t always mean the teams got their estimates wrong. Sometimes a feature sat untouched because another department hadn’t finished its part. Or the backlog grew after planning, but nobody updated the schedule. The Jira records usually contain pieces of that history, although they’re not always in the same report. One chart might show steady progress while another has a growing list of blocked issues.
The harder question is which of those figures actually explains the delay, and whether the next release is carrying the same unfinished work into a new planning cycle.
