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:

• 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

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

Open

On 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 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

1. Not ready for development backlog is taken into work

2. Poor requirements provisioning process 

3. Uncontrolled scope volatility

4. Too many stakeholders on business side

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. 

Open

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

Data source

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