/
Sprint Plan Change

Sprint Plan Change

Purpose

Sprint Plan Change shows a percentage of issues added or removed during an iteration.

How metric helps

Sprint Plan Change:

  • helps to analyze reasons for a dramatic scope change

  • shows how mature sprint planning process is

  • helps to understand how robust priorities are

  • shows how efficient the team is in refining sprint backlog ahead to eliminate blockers and depedencies during its execution

  • shows how the correct sprint goal is being set

  • shows whether sprint goal corresponds to product goal

  • shows whether team's sprint capacity is being managed properly with corresponding workload assigned

  • shows how effectively "ready for development" criteria is followed to have all stories prepared for sprint work ahead (reqs, tech notes, designs, etc)

  • shows whether additional uncontrolled changes are being added without approval

  • shows whether the team has worked out its stable velocity

  • shows whether there is change management process in place

  • shows how stable sprint scope is

If we imagine ideal planning on a project, the target for the metric here should be 0%. On the other hand, deviations can be justified, for example, if a story is rejected due to not enough details and replaced with another story. So, such deviations are subjects for discussion.

How metric works

Chart overview

Chart shows a sprint plan change in % - Axis Y by sprint - Axis X.

Chart may be viewed in:

  • Items;

  • Story Points;

  • Hours.

     

On hover over a column a hint appears with the following information:

  • Sprint name as it is in a tracking system;

  • Iteration time frame ;

  • Metric value;

  • Added or deleted scope value.

Chart legend shows the latest calculated Sprint Plan Change for Added and Removed items in percentage.

By click on a column a pop up appears with the following information got from a task tracking system: 

  • Issue ID

  • Type

  • Priority

  • Summary

What metric means

  1. Frequently changing product priorities

  2. "Hidden" activities happening during Sprint execution

  3. Scope cannot be properly estimated

  4. Not ready for development backlog is taken into work

  5. Uncontrolled scope volatility

Calculation 

Scope added = ScA/ScP*100%,

Scope deleted = -ScR/ScP*100%,

where

  • ScP – amount of initially planned scope. 

  • ScA – amount of added scope. 

  • ScR – amount of removed scope.

RAG thresholds: Green – metric value > 0% and <9%, amber – metric value >10% and <30%, red – metric value > 31%.

Calculation notes

  • Sub-items are not included in the calculation because they usually do not represent delivery value at a business level. 

  • Re-estimation of initially planning scope is not included in this metric. If it is an often case for a project, a double-bug false interpretation is possible. In order to avoid it, it is recommended to use Sprint Plan Change metric together with Estimation Accuracy one.

PerfQL

Data Source

Data for the metric can be collected from a task tracking system (Jira, TFS, Rally, etc.).

See also