Sprint Reports are a great way to measure the progress of a sprint for all teams. They provide a comprehensive view, allowing you to track progress, identify potential risks, and make informed decisions. In this article, we’ll explain how Sprint Reports work in Kendis and how you can use them to your advantage.
Key Points about Sprint Reports
Your board should be in the "Tracking" state to get the most accurate reports.
Sprint dates should be marked appropriately on the board.
The "View Report" button appears automatically based on the sprint dates.
For the currently ongoing sprint, the button is visible, and next to the Sprint name, you will see "Active" to highlight it's an ongoing sprint.
When you access the Sprint report for the first time, the report is generated automatically based on the information available in the Sprint at that point.
You may regenerate the report anytime, and all the previous versions are accessible.
It is recommended to regenerate the report for an ongoing sprint if you want to take a snapshot of the information while Sprint is active.
It is better not to regenerate the report for a closed sprint unless absolutely needed, especially if you didn't have the "Committed Load", meaning your sprint tracking didn't start properly in Kendis.
How Stories are counted in the Sprint Report
To get the proper reports, as noted above, it is a crucial step to make sure that Start and End Sprint Tracking actions are taken. There are ways to automate this at Kendis. Check this helpful article for more details.
Kendis will look if there are stories in the Committed Load and will union the stories that are added to the sprint later. This way, the stories that were in the sprint at the start and are no longer shown in the sprint are counted as part of the Planned stories.
Planned Stories =
Stories in the Committed Load
Additional Stories in the sprint
(Could be added to the sprint after the start of the Sprint)
If there are no user stories in the committed load, it means the "Sprint Tracking" wasn't started at the start of the sprint in Kendis. In this case, Kendis will count the stories currently in the sprint, so if you create the report for the older sprints, you might not see all the stories.
How to Access
You can access Sprint Reports by going to the More tab in the top right. Click on Analytics and then go to Delivery By Sprints.
Configuration of the Report
On the settings cog at the top right corner, you may select the configuration options for the reports. All these values act as "Show/hide", which means you may turn off the options and, if required, change the selection without the need to regenerate the report.
Structure of the Report
This report contains two main sections.
This section provides an overview of the combined progress of all the teams for a sprint. It has the following seven sections.
User Stories Delivery
Objectives - Progress
1. Features Delivery
This section is about providing the progress on the completion of the feature in this sprint and so far
1.1 ) Planned vs. Delivered (Sprint)
This KPI is for the features planned to be ready in this sprint. The % completion is based on the Done status of the features.
Planned: Total number of features planned to be completed in this sprint. This is an automatic calculation done by Kendis based on the planned stories, e.g., if a feature has stories in 3 sprints, Kendis will calculate sprint 3 as it's a delivery sprint. The delivery sprint can easily be visualized at the Kendis board by switching to "Phoenix mode".
Delivered: Number of features that are in "Done" status at the end of the sprints. The point to note is that even though all the stories might be done for this feature until the status of the feature is not set to the "Done category", it will not be counted as delivered. In Kendis, there is an option to mark some statuses as Done without impacting your Jira or Azure DevOps; check this for more details
1.2) Completion (All Sprints Combined)
This percentage completion combines the progress of all the sprints so far. This would give an understanding of how well you are on track to complete your features.
2. User Stories Delivery
This section provides the progress of the completion of the stories in this sprint.
The user stories completion is shown by
# of Stories Completed: Count of the user stories in the Done status category
# of Story Points Completed: Sum of the story points (Estimate) of the stories in the Done status category
The percentage completion is based on the "Completed (Done) / Total Planned."
At the end of the Sprint, Kendis will calculate the stories that were moved out of this Sprint to other Sprints.
If you haven't "Ended Sprint Tracking" at Kendis, this value will not be calculated, and you might see only 0%.
There were 28 stories planned in the Sprint, and 4 of them moved to other Sprints at the end of this sprint. Thus Spill over count is shown as 14.29%.
Scope change is the new stories added to the board in the Tracking state. To show this, let's consider an example
In the Planning state, teams planned 100 Stories in Sprint 2
During Tracking, during sprint planning, or before, they added 20 stories to the team sprints. So total stories are 120 in Sprint 2
Scope Chagne value will be: 20/120 = 20%
Before sharing the report, RTE or Scrum Master may write down in their own words how the Sprint execution went.
4) Objectives Progress Contribution
This number is calculated by looking at all the objectives and their linked Features and Stories and then identifying which are planned in this sprint.
Stories of the Features in this sprint (features are linked to the objectives)
Stories in this Sprint, and are directly linked to the Objectives.
Features and Stories that are in the Sprint and have dependencies. All the dependencies (inward and outward) are counted.
Risks linked to this Sprint or have their Target Resolution date within the Sprint dates.
Note: If the Risks are not linked to the Sprints, they will not be counted.
All the impediments that are linked to the Sprint.
This page shows the same KPIs for the Program area. However, each team has it's own data to show the completion, spill over, dependencies, risks, and objectives completion.