About this report
The Splits and Drops report shows how many story splits and drops occurred for each team in a selected PI.
If a story cannot be completed in a sprint as planned, then you have the option to split the story. When splitting the story, you can assign the remaining uncompleted items to a split story in a future sprint. You can only split a story one time.
If a sprint has already started, but during the sprint the team decides that the story needs to be removed, then a drop can be used. Drops are tracked as negative KPIs to drive better planning in the future.
This report is beneficial to Scrum Masters, team leaders and members, release train engineers, and product owners to see where splits and drops are being used by teams during sprints in a PI. It is beneficial to review the report with team members during pre- and post-PI meetings, daily stand-up meetings, and during sprint review meetings. This report is generated by selecting a specific PI.
- Select the Reports icon from the left Navigation menu.
- Start typing the report's name in the Search box.
- Once found, select the report.
Note: You can also use the categories on the left to search for the needed reports.
- PI must exist in the system and be tied to a program.
- Features must be created and tied to the PI.
- Stories must be created and tied to features.
- Stories must be assigned to sprints.
- Sprints must be created and tied to a PI.
- Teams must be created and tied to a program.
How are report values calculated?
- Split counts are pulled from the Story Management Options page; stories are split by clicking the More Options link on a Story panel, and then clicking the Split button.
- Drop counts are also pulled from the Story Management Options page; stories are dropped by clicking the More Options link on a Story panel, and then clicking the Drop button.
- Sprint sync dates are pulled from the Sprint List/New Sprint panel.
- Team names and descriptions are pulled from the Team Grid.
How to interpret this report
A high number of drops in a sprint, or by a specific team, requires investigation. Dropping a story makes it inactive. All associated development and QA tasks will also be dropped. To recover a story once you have dropped it, you will have to assign it back to the iteration in Story Planning.
A high number of splits may also be cause for concern. This usually indicates stories were blocked, not dev complete, not tested, or delayed by a dependency.
The bottom of the report provides a full count of splits and drops in the PI, along with averages per sprint. Try to keep the splits and drops at a minimum, lowering the averages each successive sprint and PI.