Milestone risk estimation

Milestone risk is a metric which measures the probability of a team that may not complete all of the current in-scope work in an active development iteration (sprint). The milestone risk estimator plug-in uses a stochastic machine learning (ML) algorithm to estimate and predict the potential percentage risk of non-completion of all work during an on-going sprint. To calculate this metric, the model uses all historical work items available in the selected value stream to train the model and extracts the required information to make the prediction.

The training data plays a vital role in the process of building, training, and predicting risk. The milestone-risk estimator model uses Cycle time metrics to estimate risk.

The training dataset is updated at regular daily intervals to add the completed work items to improve the efficiency of the risk estimator model. You must select the required value stream when integrating the milestone-risk estimator plug-in in HCL DevOps Velocity (Velocity).

The milestone-risk estimator plug-in estimates risk in the current sprint of the value stream and provides estimated results in the form of a Probabilistic Risk Estimator (P.R.E) metrics:
  • P.R.E Risk displays the evaluated risk as a percentage.
  • P.R.E Deadline displays an estimated deadline for the sprint.
To view the risk estimation, you must add P.R.E Risk and P.R.E Deadline metrics under the Delivery flow category on the Value streams page. See Adding a metric bar to value streams.

Data restrictions

The restrictions for the milestone-risk estimation model are as follows:
  • The risk estimator model does not use stories and epics to train the model or predict the risk. The current model takes in only tasks, sub-tasks, and bugs into consideration for training and predicting risk.
  • The risk estimator model considers 7 potential work days a week instead of 5 days.
  • The risk estimator model assume serial work from an individual team member. The overlapped time between multiple tickets is divided if a user works on them all and completes them in the same sprint.

    For example, consider a user who works on ticket A from day 1 through day 5, but does not update the ticket to closed until day 10 of the sprint. The user also started working on ticket B from day 6 through day 10, but does not close it until day 15 of the sprint.