Table of Contents |
---|
Purpose
Requirements Rewritten After Became Ready chart shows changes in the requirements after they became "ready for development".
...
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.:
shows changes in the requirements after they became "ready for development"
shows inadequate quality of requirements
shows whether requirements are elaborated well enough with stakeholders
shows whether requirements are reviewed and refined well enough by the development team
shows whether requirements are documented properly
shows how effective backlog refinement sessions are
shows whether demand intake flow or/and requirements analysis process is mature enough
shows whether requirements are stable from a business standpoint
shows whether micro-change management process on sprint level is in place
How metric works
Chart overview
Chart The chart shows a number of requirements - Axis Y changed by sprint/month - Axis X.
...
On hover hovering over a column, a hint appears with the following info: Number of items with Ready for Development status rewritten within the iteration.
Chart legend shows the latest metric value and the difference between this value and the previous one.
By click clicking 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.
What metric means
Expand | ||
---|---|---|
| ||
|
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 developmentmanagement>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:
"Story points" and "Time remaining" and "Region" are changed within a considered period;
or "Time estimate" is changed within a considered period;
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.
Info |
---|
...
Calculation notes
|
...
|
Data
...
source
Data for the metric can be collected from a task tracking system (Jira, TFS, Rally, etc.).
Insert excerpt | ||||||||
---|---|---|---|---|---|---|---|---|
|