Using Sprints
- Olexiy Artemenko
- 1 Commitment
- 2 Changes in work
- 2.1 Total Scope change
- 2.2 Added
- 2.3 Removed
- 2.4 Re-estimated
- 3 Completion
- 4 Applied to
Commitment
Rollover
When a team starts a sprint, it's common to have some planned issues started in the previous sprint (leftovers) and others that haven’t started yet (spillovers), which are then rolled over to the new sprint. It's typical for some issues to roll over from sprint to sprint, often getting lost in the workload.
To address this, we introduced the Rollover metric. This metric sheds light on several critical aspects:
How many story points were rolled over, affecting the team’s actual capacity for new work?
How often did a particular issue roll over from one sprint to another?
What proportion of the Initial Commitment was taken up by Rollover issues across a series of sprints? Are we comfortable with this? What do we consider a healthy pattern?
Were all incomplete issues transferred to the next sprint? Are we okay with that?
By focusing on these questions, the Rollover metric aims to provide clarity on the impact of ongoing issues and help teams evaluate their sprint planning effectiveness.
Exclude Statuses from Rollover
When a ticket moves from one sprint to the next and is “mostly done”, you do not want to see it as a rollover because only a small part of the work is left, and it does not affect the general team's scope for the next sprint. To address this, we have implemented a feature that allows you to select "mostly Done" statuses to exclude these tickets from the Rollover:
Note:
The exclude rule is applying only to issues, which were in that statuses at the start of the sprint.
if the issue was moved to selected statuses during the sprint, it won’t be filtered.
Statuses from the selected board are available for selection only.
Tips:
Review your team's workflow to decide which statuses should be excluded from the Rollover calculation.
These scenarios illustrate how excluding specific statuses from the Rollover metric can provide a more accurate and meaningful analysis of your team's progress and workflow.
Scenario 1: Managing Incomplete Issues Across Sprints
On the sprint planning, you see that the issue from the previous sprint is in the status “Done”. However, your team's workflow defines finish with the status “Released.” The issue is practically done, and you don't want it to show up as a Rollover and skew the metrics.
You can select the "Done" status to exclude the ticket from the Rollover metric for the next sprint. This way, the chart will only show issues that were genuinely incomplete in the previous sprint, providing a clear and accurate representation of the team's progress.
Scenario 2: Multi-Team Workflow Management
On the sprint planning, you see that the issue from the previous sprint is in the status “Dev Done,” which means that part of the developer’s work is finished. However, the issue is still waiting for the QA or PM contribution. So, it will be moved to the next sprint to be finished.
To see a clear and accurate representation of the developer team's progress, you can select the "Dev Done" status to exclude tickets from the Rollover metric for the developer team's next sprint. It can help to plan the sprint more precisely for each team, considering the nature of each.
Initial
The metric reflects the amount of work in Sprint before it started.
Final
The metric reflects the amount of work in Sprint after Sprint is finished.
If the Sprint is not finished, the metric reflects the current situation.
Final commitment = Initial commitment + Added work + Estimation Changed - Removed work.
Changes in work
Total Scope change
The Estimation Change, Added Work, and Removed Work metrics contribute to the variance between the Initial Commitment and Final Commitment. Recognizing this, we found it imperative to introduce the Total Scope Change metric to address the following queries:
By how many story points was the sprint scope affected?
Which issues have led to these changes?
What proportion of the Final Commitment was altered over a series of sprints? Are we comfortable with this extent of change? What do we consider a healthy pattern?
This metric aims to provide a comprehensive overview of scope adjustments during the sprint, enabling teams to better understand and manage changes to their project commitments.
Added
The metric reflects the amount of work added to Sprint before it is finished.
If the Sprint is not finished, the metric reflects the current situation.
Removed
The metric reflects the amount of work removed from the Sprint before it is finished.
If the Sprint is not finished, the metric reflects the current situation.
Re-estimated
The metric reflects the difference between estimation before the Sprint started and after the Sprint was finished.
If the issue was added during the sprint, it calculates as added work, even if their estimation was changed.
If the Sprint is not finished, the metric reflects the current situation.
Completion
The issue is completed if it has a status from the Done category and is in the last column of the Scrum Board to which it belongs.
You can set a custom Done status to manage Completion metrics.
Not completed work
The metric reflects the work not completed as a snapshot at Sprint’s end.
If the Sprint is not finished, the metric reflects the current situation.
Not completed work = Final Commitment - Completed work (final).
Completed work (Initial)
The metric reflects the amount of work planned before Sprint started and completed as a snapshot at Sprint’s end.
If the Sprint is not finished, the metric reflects the current situation.
Completed work (initial) = Completed work (final) - Completed Added work.
Apply estimation change
By default…
Completed work
The metric reflects the final scope work completed as a snapshot at Sprint’s end.
If the Sprint is not finished, the metric reflects the current situation.
Completed work (final) = Final commitment - Not completed.