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 20 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:

  • 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.


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.

Problems Indicated By Metric

  1. Not ready for development backlog is taken into work
  2. Poor requirements provisioning process 
  3. Frequently changing scope and priorities
  4. Too many stakeholders on business side
 Other
  • Issues with backlog refinement process, i.e. it's inefficient or absent at all 
  • JIRA tooling issues or human mistakes (tapping on A/C field without intention)
  • Details or tech notes are added after a story is marked as "ready for development"
  • Too actively involved and interested PO has direct access to requirements, and can edit "ready for development" user story 
  • Not robust or totally absent requirements management process 

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. 

Calculation notes

  • 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 in the calculation because they usually do not represent delivery value at a business level. 
  • If an item was returned to ready for development status several times, only the changes that were made after the last ready for development status assignment will be reflected on the metric.

Data source

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


  • No labels