Point in Time capture of Measures per Fix Version

Hi, apologies if a similar topic already exists but I haven’t found a solution I could use for my specific use case.

I’m trying to generate a set of reports that provide several metrics for multiple teams (Projects) in one view per Release (Fix Version).
These include Velocity, Predictability, count of Stories with specific Labels, Bug Issues produced per team vs. total Story Issues delivered, (visual below)

Page Filters: Release 50 (Fix Version) Team 1, Team 2, etc. (Project) Story (Issue Type)
Rows: Projects Total Stories Predictability Defects per delivered Story Customization Velocity
Team 1 10 0.9 0.9 1% 8
Team 2 23 0.4 0.4 12% 16
Team 3 1 0.6 0.6 1% 24
Team 4 12 0.99 0.99 81% 32
Team 5 23 1 1 1% 40
Team 6 14 0.45 0.45 1% 48
Team 7 15 0.5 0.5 1% 56
Team 8 3 0.3 0.3 1% 64
Team 9 1 0.43 0.43 1% 72
Team 10 24 1 1 1% 80

Since we consider multiple Issue Statuses as “Complete”, I cannot use the built in Measures to produce accurate calculations for these metrics. I’ve created multiple custom measures to capture these details as tuples like this:
Ready_For_Release_Story_Points:
(
[Measures].[Story Points history],
[Issue Type].[Story],
[Status].[Ready for Release]

)
and then combining several of these like this:
Finished Story Points:
(
Aggregate({[Measures].[ready_for_release_story_points],[Measures].[In_BAT_story_points], etc.})
)
which I then use as the basis to generate the metrics in the above table.

My issue is this:
I need these to be a point in time capture of these metrics, so the data is reflective of the values when the Release actually closed.

For example, we’ve moved on to Release 51, but since teams have closed out any unfinished Stories post release, the Velocity values in my report would continue to increase per Team, making any metrics relying on these inaccurate.

These values are to be compared to previous Releases to report on Trends, so as the values change, they become less and less accurate to the point in time the Release actually completed.

Is there a way to capture the point in time values for these metrics? I’m aware of the Transition Dimension, and the possibility of Including the the Fix Version’s Release Date in the Time Dimension and include in my tuples, but I’ve struggled to make these work in any meaningful way.

I’m trying to avoid making duplicates of these reports per release, and that filtering to a different Fix Version would dynamically make the measures reflect the values at the end of each release, so we can accurately measure increases/decreases as part of our Trend analysis.

Also, is there a best practice to measure sprint story commitments over a Fix Version? I’m currently just summing the total story points of all Story Issues with the Fix Version, but I don’t think this is an accurate way to capture this value.

I know the ask is a bit complex, and I appreciate any help or guidance that could be provided for my situation!

Kind Regards,
Mark

Hi,

For point-in-time capture of metrics per Fix Version, you need to use the Fix Version release date in your calculations combined with Transition Status dimension for historical accuracy.

This is how you may proceed:

  1. To represent historical data, use the dimension “Transition Status” (see documentation: Import issue change history).
    Remove “Status” dimension from your calculations as it represents issues by their current status, not the one they were in the Fix Version or a specific point in time.

  2. Use the “Fix Version” dimension on report rows and pages to show individual projects and filter by the version name. Choose the by Name hierarchy on rows and page; see picture below.
    This approach allows reading the version release dates for each project on rows.

  3. You can capture Story Points for Stories that were in a specific transition status, “Ready for Release”, on the release date. Use the function DateMember to find a specific Time member matching the fixed version release date.

    ([Measures].[Story Points history],
    [Issue Type].[Story],
    [Transition Status].[Ready for Release],
    --find a Time member that matches release date for each project release
    [Time].[Day].DateMember(
      [Fix Version].CurrentHierarchyMember.Get('Release date') )
    )
    
  4. For sprint commitments over Fix Version–mixing sprints and versions can be complex; it’s better to choose one as your primary planning unit.
    Instead of just summing story points, consider using measures like “Sprint Story Points committed” filtered by your Fix Version. This approach will give you consistent historical metrics that don’t change as teams continue working post-release, making your trend analysis accurate. More details on Sprit scope metrics described in the documentation: Jira Software custom fields
    You can start with a release burn-down report template and adapt it to your needs: Release burn-down by Sprints - Issues - Jira Demo - eazyBI

Best,
Zane / support@eazyBI.com

Hi Zane,

Your response is much appreciated! I’ll try to refactor my reports the way you’ve suggested and will let you know how it goes!

Kind Regards,
Mark

Hi Zane,

I’ve attempted to refactor the report in the way you’ve suggested, but I’m still having trouble getting the metrics that I need.
I’m just returning Projects on the report Rows for now, as I can specify Start and End dates for each Release/Sprint as a Time member
(my org does not populate the Fix Version dates on Jira, and I can filter between Sprint and Release level dates while using the same Measures this way)

I cannot use [Transition Status] in the way you’ve outlined to return story points worked on within a specified time frame, because:

  1. During each Sprint, there will still be stories that were completed in previous sprints, but flowed in as “Committed Stories” to the current sprint and have a status of “Ready for PO Acceptance”, “In PO Acceptance”, “Ready for Release”, etc. We do not want these counted, but I believe they would if we used [Transition Status].

  2. Only stories that moved past “In BAT” to a valid Status (outlined in below Measure) within a sprint’s timeframe is considered “Completed Work” within that time.

  3. If a Story moved from “In Test” to “In BAT” within the Sprint, but back to “In Test” again (due to issues found), I believe the story would be counted twice for [Transition Status].[In BAT]

  4. If story that transitioned to one of the statuses outlined in the below Measure, but again transitioned to statuses further along the pipeline (e.g. from “In PO Acceptance” to “Ready for Release”),
    we would not want these story points to be counted twice.

The below Measure returns the correct amount of stories “Completed” within a Sprint’s/Release’s start-end dates (All Completed Stories (by Transition)):

However, I cannot return the amount of Story Points associated to the stories returned in this Measure.
I’ve attempted many different approaches using both “Story Points History” and “Issue Story Points” but typically get “0.00” returned:

Report Layout:

Time Page Filter:

Story Point Measure (currently returning zero for all Transition values mentioned in first Measure above):

Would appreciate any additional help on this.
Kind Regards,
Mark

Hi @MarkH401,

I see yuor have found the workaround for most of the complexities for this report. The report layout looks good, considering your project and sprint configuration.

It is an excellent starting point if you know how to get the correct count of issues that were completed by the Team during the selected period. You can make a similar calculated measure to sum up the story points of issues that were completed (went through specific transition statuses) during the timeframe. The calculation would iterate through individual issues; if an issue went through particular transitions, then sum up its story points.

The expression might look like this:

Sum(
  --iterate through individual issues
  Filter(
    Descendants([Issue].CurrentMember,[Issue].[Issue]),
    --check if issue has changed status sincethe  beginning of reporting period
    DateCompare(
      [Measures].[Issue status updated date],
      [Time].CurrentHierarchyMember.StartDate
    ) >= 0
  ),
  CASE WHEN --issue moved through completion transitions
  Aggregate(
    {
      [Transition].[In Test => In PO Acceptance],
      [Transition].[In Test => Ready for PO Acceptance],
      [Transition].[In Test => In BAT],
      [Transition].[In Test => Ready for BAT],
      [Transition].[In Test => Ready for Release]
    },
    [Measures].[Transitions to status issues count]
  ) > 0
  THEN --sum up story points
    [Measures].[Issue Story Points]
  END
)

Best regards,
Zane / support@eazyBI.com