Program increment/sprint metrics

About this report

The Program Increment/Sprint Metrics report shows day-by-day metrics/statistics for a selected sprint, including the following information:

• Meeting Attendance = percentage of attendance for sprint planning, daily standup, and sprint review meetings
• Absent List = a list of absent attendees from the sprint planning, daily standup, and sprint review meetings
• Scope Creep (added tasks) = count of tasks and task hours added per day
• Scope Creep (dropped tasks) = count of tasks and task hours dropped per day
• Burn % = percentage of tasks hour logged compared to the total estimated task hour
• Burn Hours = count of actual task hours burned/logged for the sprints, per day
• Bug Fix % = percentage of allocated tie used to fix bugs
• Bug Fix Hours = count of total hours spent fixing bugs
• Open Impediments = count of open impediments per, day
• Defects Opened = count of defects opened, per day
• Defects Closed = count of defects closed, per day
• Defect Hours Spent = count of actual defect hours burned/logged for the sprints, per day
• Code Reviews = count of code reviews conducted for the sprint, per day
• Story Count = count of stories committed during sprint planning plus any new stories added to the sprint, less the number of accepted stories during sprint, per day  
• Task Count = total count of tasks on the first day of the sprint plus any new tasks introduced during the sprint, per day
• Stories With no LOV = count of stories with no Level of Value data, per day
• Stories with no LOE = count of stories with no Level of Effort data, per day

This report is most useful to Scrum Masters, team leads, product owners, or release train engineers who require a day-by-day view of the sprint. The report provides visibility into how the work is progressing. It is beneficial to review the report with team members during daily standups and the sprint retrospective.
Prerequisites

1. PI must exist in the system, and be tied to a program.
2. Teams must be created and tied to a program. 
3. Sprints must be created for each team and tied to a PI. 
4. Stories with point values must be created. 
5. Stories must be assigned to sprints. 
6. Tasks must be created and assigned to stories.

How are report values calculated?  

• Meeting Attendance = pulled from the attendance records of the sprint planning, daily standup, and sprint review meetings
• Absent List = pulled from the attendance records of the sprint planning, daily standup, and sprint review meetings
• Scope Creep (added tasks) = task and hour counts are pulled from the Tasks page
• Scope Creep (dropped tasks) = task and hour counts are pulled from the Tasks page
• Burn % = total Expected Hours Burned divided by Actual Hours burned for tasks, expressed as a percentage
• Burn Hours = burn hours counts are pulled from time (task hours) logged against stories
• Bug Fix % = total time spent/hours of allocation * 100%; pulled from Defects page
• Bug Fix Hours = hours are pulled from Defects page
• Open Impediments = impediment counts are pulled from the Impediments page
• Defects Opened = defect counts are pulled from the Defects page
• Defects Closed = defect counts are pulled from the Defects page
• Defect Hours Spent = defect hours spent counts are pulled from time (defect hours) logged against stories
• Code Reviews = code review counts are pulled from the Code Reviews grid
• Story Count = story counts are pulled from the Story page
• Task Count = task counts are pulled from the Tasks page
• Stories With no LOV = story LOV counts are pulled from the Story page
• Stories with no LOE = story LOE counts are pulled from the Story page

How to interpret this report

An overall scan of the report will quickly give a feel for the day-by-day health of the sprint. Keep an eye out for problem areas, for example, low meeting attendance, high numbers of stories with no LOE or LOV, and low numbers of closed defects. Teams that analyze performance and make adjustments day-to-day will get the most value from this report.