Program dashboard

About this report

This report can be used as a coaching tool by release train engineers, Scrum Masters, team leaders, and product owners to assess the effectiveness and health of the sprint teams. It is beneficial to review the report with team members during pre- and post-PI meetings, and during sprint review meetings. This report is generated by selecting a specific program increment and program within the program increment. 

To navigate to this report:

If you’re using the new navigation:

1. Select Programs in the top navigation bar and select the program you want to view information about.
2. On the sidebar, select Reports in the list of options.
3. Select Program snapshot; the report displays.

If you’re using the old navigation:

1. Select the Reports icon from the left Nav menu.
2. Start typing the report's name in the Search box.
3. Once found, select the report.
   Note: You can also use the categories on the left to search for the needed reports.

The program dashboard report captures:

1. Sprints - How many sprints the team ran during the program increment. 
2. Last Sprint - The short name of the last sprint completed by each team.
3. Story Completion Ratio: Ratio of how many stories the team completed of the planned number. 
4. Point Completion Ration: Ratio of how many points the team completed of the planned number.
5. Velocity Variance:  The variance between the team’s actual average velocity across all sprints of their average or baseline velocity.
6. Dev Ratio: The percentage of developers on the team compared to other roles. 
7. QA Ratio: The percentage of testers on the team compared to other roles. 

Prerequisites

1. PI must exist in the system, and be tied to a program. 
2. Sprints must be created and tied to a PI. 
3. Teams must be created and tied to a program. 
4. Teams must execute sprints rather than Kanban. 
5. Team Members must be assigned to the team and have an associated team role.
6. Sprint Review meeting must be run via Jira Align's sprint review module. 

How are report values calculated? 

• Sprints is captured from the team sprint list for each team working in the PI.
• Last Sprint value is the short name of the last sprint completed by each team.
• Team emotion is captured after every sprint on the Sprint Review Meeting page; options include:
• The next Sprint is on track for this team. Sunny skies ahead.
• The next Sprint is on track but many risks loom ahead. Clouds are forming.
• This team's portion of the plan is in trouble. Thunderstorms overhead.
• Story Completion Ratio: Number of Stories Delivered / Number of Planned Stories
• Point Completion Ratio: Number of Points Delivered / Number of Planned Points
• Velocity Variance: recent velocity across all sprints measured / average velocity
• Dev Ratio: Is the percentage of developers on the team compared to other roles.
• QA Ratio: Is the percentage of testers on the team compared to other roles.  

How to interpret this report

A sunny skies indicator is what you are after. After all, a positive, optimistic team will be more effective in reaching shared goals. Too many clouds or thunderstorms means team dynamics, workload, and impediments should be closely examined to see where improvements can be made.

For story and point completion ratios you are looking for your teams to have a consistent predictability ratio of 10-15% or less variance from what they planned.  Meaning that a team consistently delivers 85-90% of their estimates.

Monitoring the velocity variance helps teams to become more predictable and stable over time. As the team retrospect on the variability in this metric we look to see what the causes of the variance were. Typically, variances in velocity are caused by: not identifying or managing risks and dependencies, over committing at the start of the sprint, having too many items in process at once (not managing WIP) or allowing for injects into the sprint.

In some cases, not having cross trained teams with all the skills needed to complete stories will also cause variance in the three metrics above.  If the reason for velocity variance is the team didn't have the right skills to complete the stories.  Look to the ratio of devs and testers on the team.  Are there too many developers and not enough testers?  Too many testers and not enough developers?  If so, consider using pair programming or XP approaches to cross-skill the team.