Planned vs delivered issues in last 5 sprints

I am looking for a bar chart which represents planned vs delivered issues .Below is the logic for it


Definition of delivered - Accepted or above, before the end of the iteration(sprint)/PI (release)

Definition of planned - assigned to iteration before 48 hours (selectable 1 or 2 days) from the iteration/release start date

This chart should represents the data for the last 5 sprints .Any suggestions how this can be done ?



eazyBI provides several standard measures of sprint scope management. It is possible to build the chart as you describe by adjustments of those measures for the sprints; it is not possible to reproduce the same solution if you wish to track the scope by release (e.g., Fix version).

For the delivered story points eazyBI offers the standard measure “Sprint issues completed”, which is the number of the issues at the end of the sprint in the status category “Done”. You can adjust this measure with other statuses if this definition does not precisely match your workflow in Jira.

The definition of the “planned” would require to create a new calculated measure for the counting. There might be two options to go with the custom measure like that. First is to check precisely the time when an issue was added to the sprint, which would require iteration over all the issues and referring to the hidden measure in eazyBI giving the timestamp of when the issue was added to the sprint. Considering that you have Sprint dimension in the report rows, the formula would be the following:

   [Measures].[Sprint issues committed]>0 --issue added to the sprint before start date
   ([Measures].[Sprint issues added]>0 AND --issue added to sprint within 48 hours after start date
    DateDiffHours([Measures].[Sprint start date],
    ([Measures].[Transition to last timestamp],
      [Transition Field].[Sprint status],
      [Sprint Status].[Active],
    -- An issue was added or created in an active sprint
    [Issue Sprint Status Change].[(none) => Active])
  )) < 48)

This pattern might also be reused to count the planned/unplanned delivered issues.

Another solution of the planned issues would be more efficient from the performance point of view but would allow only to track the “planned issues” with the precision of days:

[Measures].[Sprint issues committed]
Sum( -- count the added issues within two days from a sprint start date
  {[Time].[Day].Datemember([Sprint].CurrentMember.Get('Start date')):
   [Time].[Day].Datemember(DateAddDays([Sprint].CurrentMember.Get('Start date'),2))},
   [Measures].[Sprint issues added]

Please, check also the Demo account for the sprint scope report examples.