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>Issue types to track scope readiness for development;
- criteria Project settings>Scope management>Track changes in requirements.
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.).