Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

Purpose

Requirements Rewritten After Became Ready chart shows changes in the requirements after they became "ready for development".

How metric helps

Requirements Rewritten After Became Ready helps to highlight an inadequate quality of requirements. The more changes are made after the status became 'ready for development' the worse because it means there are questions (e.g. from a development team) posed after a requirement was considered as final. So it is not elaborated well enough with stakeholders or / and documented improperly.

How metric works

Chart overview

Chart shows a number of requirements  - Axis Y changed by sprint/month - Axis X.


On hover over a column a hint appears with the following info: Number of items with Ready for Development status rewritten within iteration.

Chart legend shows the latest metric value and the difference between this value and the previous one.

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

  • Issue ID;
  • Type;
  • Priority;
  • Summary.

Calculation 

Requirements Rewritten After Became Ready is measured as a number of changed items satisfying both criteria:

  • criteria Project settings>Scope management>Definition of Ready;
  • criteria Project settings>Scope management>Track changes in requirements.

Track changes in requirements works as follows:

1. Fields within one Issue field are connected with the logical AND. So if only all selected fields are changed in a requirement, it means a change. 

Example:

A bug is counted in the metric as a changed requirement if all criteria below are met:

  1. "Story points" and "Time remaining" and "Region" are changed within a considered period;
  2. or "Time estimate" is changed within a considered period;
  3. or "Story points" and "Actual outcome" are changed within a considered period.

2. Issue fields are connected with the logical OR. 

RAG thresholds:  Red - metric value ≥ 5; Amber - 2 < metric value < 5; Green - metric value ≤ 2. 

Assumptions

  • If an item is changed several times in different iterations it will be counted as a changed item for each iteration.
  • Sub items are not included into the calculation because they usually do not represent delivery value at a business level. 

Data Source

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


  • No labels