Version burndown on remaining estimated hours

Hi,

I’m trying to create a burndown chart for a certain version, based on the remaining estimated hours.
It would look something like this:

However, when I use the measures ‘Remaining estimated hours’ or ‘Remaining estimated hours change’ the data does not look useful. Lots of empty or null cells.

In my team the remaining estimates change daily. This can be either by logging hours and Jira auto-updates the remaining estimate or by updating it manually.
How do I get this data visualized in EazyBI?

1 Like

Hi @MrDaggins,

You are close to the right solution by using historical measures (https://docs.eazybi.com/eazybijira/data-import/jira-issues-import/import-issue-change-history). To get the amount of the remaining estimate at the end of each period (day, month, etc.) you might want to use historical measure “Remaining estimate hours history”.

Best,
Zane / support@eazyBI.com

Hi @MrDaggins

did you manage to finish the graph as shown in the image above?

I’m having trouble creating a chart this way.

Regards.

@Wanderson, how did the measure “Remaining estimated hours history” work in your report and from the screenshot?

The idea for the report is similar to other burndown reports (for example, here is the instruction for building burn-down reports) and use historical measures to see changes over time, a calculated measure based on version start and end dates for a guideline, and some indicator to highlight which dates (periods) are in the selected time period (between start and end dates).

Use measure “Remaining estimated hours history” on columns to show the change at the end of every selected period.

For the guideline, you might want to use Original estimated hours to get the total expected effort for the version, and version properties Start and Release dates to assess the length of the version and how much should be done in each day. The expression might look like this:

-- annotations.group = Time tracking
CASE WHEN --selected date in version
  DateBetween([Time].CurrentHierarchyMember.StartDate,
    DateWithoutTime([Fix Version].CurrentMember.get('Start date')),
    [Fix Version].CurrentMember.get('Release date')
  )
  OR 
  DateInPeriod(
    [Fix Version].CurrentMember.get('Start date'),
    [Time].CurrentHierarchyMember
  )
THEN
  --version total scope. Original estimated hours of all issues in selected version.
  ([Measures].[Original estimated hours],
  [Time].CurrentHierarchy.DefaultMember)
  *
  --remaining days till the version release
  (
    DateDiffWorkdays(
      DateWithoutTime([Fix Version].CurrentMember.get('Start date')),
      DateWithoutTime([Fix Version].CurrentMember.get('Release date'))
    ) -
    DateDiffWorkdays(
      DateWithoutTime([Fix Version].CurrentMember.get('Start date')),
      [Time].CurrentHierarchyMember.StartDate
    )
  ) /
 --Version length in days
  DateDiffWorkdays(
    DateWithoutTime([Fix Version].CurrentMember.get('Start date')),
    DateWithoutTime([Fix Version].CurrentMember.get('Release date'))
  )
END

Replace calculated measure “Time within Sprint” for filtering relative periods with “Time within Version”. This measure is handy to improve report readability and show only those weeks or days that are within Version Start and Release date limits. The expression is given in the Demo account as well:

CASE WHEN
 DateBetween([Time].CurrentHierarchyMember.StartDate,
 [Measures].[Version start date],
 [Measures].[Version release date]
 )
THEN 1
END

Here is a report example in the Demo account: Time Tracking Burndown in Selected Version - Issues - Jira Demo - eazyBI

Best,
Zane / support@eazyBI.com