Using Sprints

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:

  1. How many story points were rolled over, affecting the team’s actual capacity for new work?

    image-20240426-073631.png
  2. How often did a particular issue roll over from one sprint to another?

    image-20240426-073905.png
  3. 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?

  4. 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.

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:

  1. By how many story points was the sprint scope affected?

  2. Which issues have led to these changes?

  3. 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.

 

Applied to