[VSA] Stage times should be the time work items spent in a stage during the selected date range (research issue)

Overview

VSA shows median times for each stage. A user can select a date range and the median stage times will change to show data for issues/MRs that were created within the date range, regardless of when the issue/MR was actually in the stage.

Example:

  1. Today is May 5
  2. I select a date range of Jan 1 - Jan 31
  3. VSA finds all the issues/MRs that were created in January and calculates a median stage time based on how long it took between the start event and end event, regardless of when the events happened. For example, an issue created in January may have entered the Code stage in March and exited the Code stage in April. This is still counted towards the stage time shown when the Jan 1 - 31 date range is selected.

Problem to solve

This approach to applying the date range to stage times can be confusing, and not what users expect. Customers want to see the stage time for the date range selected. For example, if the selected date range is Jan 1 - Jan 31, users want to see the median stage time based on anything that entered and exited the stage during that date range. This allows them to see how stage times were trending during that period.

Quote from customer:

Often times we create issues far before they actually get worked on. We want to capture the stages completed during the date period selected, regardless of when the issue was created. This way we can see trends of different stages/workflows overtime and address concerns as we see them trending. Attaching them to the week they were created doesn't give me this insight at all.

Proposal

  • Research options for calculating stage time based on time spend in the stage during the selected date range, regardless of when the issue/MR was created.
  • Identify and document any flaws in this idea
  • Document different options for implementing the new calculation, including an option that assumes unlimited time and resources, an option that involves minimal changes, and an estimate of system performance for each option

Open questions

  1. With the new calculation, does it still make sense for the Overview metric to be an aggregation of each stage time?
  2. What would this change mean for the Lead Time and Cycle Time metrics?

References

Edited by Dan Jensen