Start with the video first to get a better grasp of the topic!
|
Skip Ahead to: |
Overview
Any work that was committed by your team for a sprint but couldn’t be completed during that sprint duration, is considered as spillover work. So, looking at the spillover percentage one can determine how well the team had estimated before committing to the scope and draws attention if the spillover needs to be reduced in future sprints.
However, the spillover percentage can be a good indication of how the team is trying to improve its throughput. For example, if the spillover percentage is steadily between 0 to 10 percent then it might indicate that the team is trying to improve its throughput.
Using the Spillover widget, you can visualize the absolute count or story points of spilled-over workitems for maximum up to last 12 sprints in a Bar or Line Chart.
Configuration
To plot a Spillover Work Trend, perform the following steps:
1. Open Analytics Builder and go to Standard Widgets. Click the Spillover Work Trend from the Agile Analytics group of metrics.
2. The Setting page appears where you can specify the settings for the widget:
Widget name: Modify the name, if required.
Data Criteria
1. Select filter: Open the Select filter drop-down and choose an existing item filter for your sprints from the drop-down. You can also create an item filter by clicking the Add icon. Moreover, you can also modify an existing filter by clicking the Edit icon. The specified number of sprints matching to the applied filter will be plotted in the widget.
2. Sprint Selection: There are two ways to select the sprints for plotting the chart.
a. Fixed list of Sprints: Select this option to choose specific sprints from the given date range. To select specific sprints, specify a date range in the From and To fields. All the sprints whose start date falls between the given date range will be displayed. Select the sprints that you want to plot in your widget. Note: Only past sprints (sprints with an end date earlier than the current date) are available for selection.
b. Dynamic list of Sprints: Click this option to dynamically plot the chart based on the past sprints (sprints with an end date earlier than the current date). To select the dynamic sprints, enter the number of the sprints in the Sprints field. Note: You can select a maximum up to 99 sprints. By default, the past 12 sprints are selected.
3. Show Data Labels: Select this option to show the labels on the chart.
4. Show Trend Line: Select this option to show the trend based on the linear progression of the selected analytics.
5. Show value as a percentage: Select this option to show the value as a percentage on the chart.
Dimension and settings
6. Y-axis: Select the attribute, unit of measurement, and chart type in which you want to plot data on the Y-axis of the widget.
Interpretation
The sprint names are displayed on the X axis and the Estimates (Points)/ Workitem Count are shown on the Y axis. The trend line shows the increasing or decreasing pattern of the Spillover Work.
Spillover work trend is derived on the basis of the difference between the workitems committed as the sprint scope (on sprint start date or scope freeze date) and the incomplete workitems at the end of the last day of the sprint.
Workitems are classified as spillover in the following events:
1. Creation of a spillover card from the Execution Board
This action is generally taken when a user starts working on a card but cannot complete it as the time taken by the card is longer than originally planned. In this case, the user creates a spillover card so that the effort spent against the workitem is considered for the sprint. However, the workitem is considered a spillover because the committed scope of the work could not be completed.
Note: When a Spillover card is created, the name of the source release and source sprint are saved in the Spillover Release and Spillover Sprint fields respectively.
2. Un-tagging a workitem from the sprint
This action is generally taken when a user doesn’t start working on a card (as other works might take longer time) and therefore cannot complete it in the sprint. In this case, the user simply un-tags the sprints from the card and prioritize it for an upcoming sprint. Since, no work was accomplished as committed for the sprint scope, the workitem is considered as spillover.
In the above chart, there are two sprints that have 20% spillover. However, the overall derivation of the spillover is different for both. This can be seen upon drill-down.
When you drill-down on SP1.2 (V1), you will notice that out of 30 workitems, originally planned as the sprint scope, 6 workitems were untagged. That’s why the spillover % has been derived as 20%.
When you drill-down on SP2.2 (V2), you will notice that out of 30 workitems originally planned as sprint scope, 9workitems were untagged, 4 workitems were added to the sprint scope and 1 spillover workitem was created for originally planned workitem. The spillover percentage is derived in the following manner = [(9 – 4 + 1)*100/30] = 20%
The same logic holds true when equal number of workitems are removed and added to the sprint. In such a case, the spillover work is shown as 0 as seen for sprint SP 3.1. However, you will still be able to view the scope changes upon drill-down from the tabular data:
The Chart also shows us the following summary on top:
1. Average: Shows the average value of sum of estimated points or count of workitems that got spilled over in the sprints seen on the widget.
2. Last 3: Shows the average value of sum of estimated points or count of workitems that got spilled over in the last three sprints seen on the widget.
3. Lowest3: Shows the average value of sum of estimated points or workitem count of 3 sprints that have the lowest spillover amongst sprints seen on the widget.
4. Highest 3: Shows the average value of the sum of estimated points or workitem count of 3 sprints that have the highest spillover amongst sprints seen on the widget.
Note: For the Medium size widget, only Average and Last 3 values are shown on top.
Best Use
Based on the spillover work in the past sprints, one can plan their future work accordingly.
1. The average of spillover estimated points or workitem count can give you a perspective of whether your team is good at delivering on what they committed to as the sprint scope. If the average is high, then it indicates that the team is not estimating well enough and taking up more work than what they can deliver.
2. If the spillover work is decreasing continuously, then it indicates the team is able to estimates its throughput well. Similarly, if the spillover work is increasing, then either the team is trying to improve their throughputs or is not performing as expected.
3. Since the final spillover workitem count or estimate points is getting derived on the basis of the difference between the sprint scope on the start date or scope free date and the last day of the sprint, it is important to view the drill-down to know if workitems were purely removed, spilled over, or the overall spillover work is reduced by adding new workitems.