A clearer path
to getting started.

New Jira Dashboards

1. Introduction

The Redline Burndown Widget is a powerful tool for tracking project progress and estimating completion dates. It provides a visual representation of work completed over time, helping teams to monitor their progress and identify potential delays or issues.

This guide covers the Red Line Burndown widget on the new Jira dashboards, including dashboard filters, configuration previews and saving changes.

NOTE: The Red Line Burndown only works with Jira data. Dashboards can include data and filters from other products, but those data sources are not supported by this widget. Some Jira dashboard filter fields are also not supported. See Dashboard Filter Fields and Unsupported Dashboard Filters below.

2. Adding the Widget to Your Dashboard

1. Open your dashboard and enter its edit mode if necessary.
2. Click "Add widget" and search for "Crimsalytics Red Line Burndown".
3. Select the widget and open its configuration panel.
4. Choose the Burndown Type and set the Start Date. New widgets default to Dashboard only as the Filter source, so you will also need to select a supported Jira dashboard filter, such as a Space name, to define which issues to include.
5. Use the dashboard's Add or Save control to finish adding the widget, then save the dashboard if it is still being edited.

NOTE: A newly added widget must be saved before it can display your burndown. If you see "Save the widget and dashboard to view your burndown chart", finish saving the widget and dashboard. The sample chart shown in the widget picker is a preview and does not use your Jira data.

3. Configuring the Widget

After adding the widget, you'll need to configure the following required fields by using the widget's Edit control to open the configuration panel:

• Filter source. New widgets default to Dashboard only, which requires a supported Jira dashboard filter selection. Select a Jira filter or enter JQL when using Widget only or Dashboard AND'd with widget Filter/JQL.
• Burndown Type
• Start Date
• Chart Time Zone (in the Advanced Settings section at the bottom and automatically defaults to your time zone) NOTE: For a simple chart, you can stop here and use the dashboard's Save or Add control. However, there are many additional configuration options available to customize the chart to your needs. See below documentation for more details on each section.

Widget Title

• Widget title: Enter a title at the top of the configuration panel to identify this burndown, such as "Release 2.0 Burndown" or "Team A Progress". The title is shown above the chart and is also used when expanding the chart to fullscreen. Leave the field blank to use Crimsalytics Red Line Burndown. Use Update preview to see a title change, then Save to keep it.

Filter Source

The Filter source determines which Jira issues are included in the Primary Burndown:

• Dashboard only: Use the supported Jira filters selected on the dashboard. This is the default for a new widget. The widget's own Jira filter or JQL query is not used in this mode, even if one has been entered. If no supported filter selection remains, the chart will ask you to apply a dashboard filter instead of calculating an unrestricted burndown.
• Dashboard AND'd with widget Filter/JQL: Include issues that match both the supported dashboard filters and the widget's saved Jira filter or JQL query. For example, you can use the dashboard to select a Space name and use the widget's JQL to limit the chart to bugs in that project. If no dashboard constraints apply, the widget's saved query is used.
• Widget only: Use only the widget's saved Jira filter or JQL query. Dashboard filters do not affect the chart in this mode.

Existing widget configurations without a saved Filter source retain Widget only behavior.

The configuration setting for "Additional Burndown Charts" are always subsets of the Primary Burndown's effective issue selection. Their JQL is ANDed with the primary scope after applying the selected Filter source. The Resource Model, budget and milestone values remain the values you configure; dashboard filters do not change those settings.

Dashboard Filter Fields

The new dashboards use field names that may differ from the names used in Jira's Query Language (JQL). The following table shows how the widget translates the standard Jira dashboard filter fields:

Custom fields can also be used when the dashboard identifies a searchable Jira custom field and the selected comparison is supported by Jira. For example, customfield_10041 maps to JQL cf[10041]. Custom field IDs differ between Jira sites, so a field number from another site's configuration may not identify the same field on your site.

NOTE: Work item completed date and Work item resolution date both map to JQL resolved in this widget. A transition to a Done status does not necessarily set Jira's resolution date, so the widget's completed-date selection may differ from another dashboard chart that uses status-transition history.

Using Dashboard Filters:

• All: For supported selection fields, All adds no constraint for that field. Selecting All for every field does not provide an issue scope for Dashboard only mode.
• None / Unassigned / No parent / No team / No sprint: These selections are different from All. They select an empty Jira field where supported. For Sprint, No sprint means sprint IS EMPTY; it does not mean all issues without an active sprint, since an issue can retain a closed sprint value.
• Multiple selections: A selector can include more than one value. For example, selecting a fix version and None includes issues assigned to that version OR issues with no fix version. The widget retains the dashboard's AND/OR grouping for the supported filters.
• Date ranges: Supported date fields accept the dashboard's Today, Last, Next and Absolute date selections, including days, weeks, months and years for relative ranges. Both endpoint dates are included. For example, Work item due date set to Today uses due >= startOfDay() AND due <= endOfDay(). Jira evaluates these relative dates in its query time zone.
• Chart dates: A dashboard date filter selects issues by the mapped Jira field. It does not set the chart's Start Date, End Date, Max Initial Chart Date or Plan Anchor Date. Configure those dates separately in the widget.
• Field labels: A filter's displayed label can be renamed. Renaming it does not change the underlying Jira field it filters.

Unsupported Dashboard Filters

The following standard Jira dashboard fields are not currently supported:

Additional limitations:

• Other products: Data and filters from products other than Jira are not supported. Adding them to a dashboard does not make that data available to the Red Line Burndown.
• Sprint status: Only Active, Future and No sprint selections are currently mapped. Other sprint-status values, including a Closed value if offered, are not supported by this selector. You can use Widget only with a Jira saved filter or JQL query to define a different sprint scope.
• Other fields and comparisons: A field must be available as a searchable Jira field and support the selected comparison. Unrecognized fields, unsupported custom-field selections and unrecognized date or function selections cannot be applied. Some Jira sub-product-specific fields or filters supplied by another app may also be unsupported.

When a dashboard filter has elements that cannot be applied using Jira JQL, a yellow caution icon appears in the chart toolbar. Click it to see the unsupported data sources or Jira fields and the reason they were not applied.

NOTE: Unsupported filters are ignored by the chart's Jira query. Supported filters are still be used, so the chart's scope may differ from other widgets on the same dashboard. Always review the caution icon before comparing results. If Dashboard only has no supported constraints left, the widget displays a message and does not start a calculation.

Previewing and Saving Changes

Opening the widget's configuration panel and changing settings do not automatically start another burndown calculation. This enables users to make several changes before refreshing the chart.

1. Make configuration changes.
2. Click Update preview beside Edit in fullscreen at the top of the configuration panel to apply the current form to the preview and refresh chart data from Jira. This does not save the widget.
3. If more changes are made, Preview is out of date appears beside Update preview and above the matching chart. Click Update preview again to see those changes.
4. Click Save to keep changes. Save also requests fresh chart data even if the form has not changed.
5. Use the dashboard's Cancel control to discard unsaved configuration changes.

Configuring in Fullscreen

The new Jira Dashboard configuration view has limited horizontal space, so there's an Edit in fullscreen button at the top of the configuration panel to provide more room to edit settings. Click Apply changes to return the changes to the original configuration form, then save there to finish. NOTE: In full screen configuration edit mode, clicking Apply changes by itself does NOT save the widget.

Burndown Settings

• Burndown Type: Choose between "Story Points" or "Time-Based" burndown.

  • Story Points: Jira's built-in Story Point field is actually a custom field with the name Story Points. This is used to track progress based on story point estimates. If necessary, you can override the default field by setting the name of the custom Story Point Field (e.g., "customfield_10041"). See below for further details on overriding this field. An error message will appear if the field is not found.
  • Time-Based: Uses Jira's built-in time tracking fields (Original Estimate, Remaining Estimate, and Time Spent) to calculate progress. - When using Time-Based, you need to make sure that you either set the remaining estimate to the proper value (usually 0) when the status is changed to a "Done" state or you need to configure Jira to automatically set the remaining estimate to 0 when the status is changed to a "Done" state. Here's a link to an Atlassian article on how to configure this: https://confluence.atlassian.com/jirakb/set-remaining-estimate-to-0-on-post-function-304579031.html - For Time-Based burndowns, you can also select your preferred time unit (Days or Hours) for display. This affects how time values are shown in the chart and table. The system uses a standard conversion of 8 hours = 1 day.

• Query Mode: Choose between "Filter" or "JQL" to define which issues to include in the burndown. This query is used with Widget only or Dashboard AND'd with widget Filter/JQL. It is not used with Dashboard only.

  • Filter: Select from your saved Jira filters. The filter's JQL will be used for the burndown calculation.
    • NOTE: if a filter is selected and a Configuration Error states Changelog is empty. Please check your JQL Query in the widget configuration and test that it returns issues in the Jira Filters page. Please update the widget configuration and try again.
    • First open the filter to make sure that there are Jira Issues returned by the filter.
      • If the filter returns 0 issues, then fix the filter.
      • If the filter returns at least one issue, then it's likely a permissions issue. On the Jira Filters page, edit the filter and under Viewers select My organization, press Add and hit Save. This will make the filter visible to all users in your organization including the Red Line Burndown widget. After doing so, refresh the dashboard and the error should be resolved.
  • JQL: Enter a custom JQL query directly.

• Additional Burndown Charts: Add extra burndowns based on specific criteria. This feature allows you to create and compare multiple burndown charts within the same widget. Each additional burndown can have its own JQL query, enabling you to track different subsets of issues or teams.

  To add an additional burndown:

  1. Click in the first empty row in the Additional Burndown Charts section.
  2. Provide a name for the new burndown (e.g., "Team A Burndown" or "High Priority Issues" or "Added Scope" or "Bugs").
  3. Enter a JQL query to define which issues should be included in this burndown. NOTE: this filter will be ANDed with the primary issue selection to create a subset of issues for this burndown. That selection includes the supported dashboard filters when the Filter source uses them.
  4. The burndown will automatically pick a line style for the burndown to distinguish it from all the other burndowns.

  Benefits of using Additional Burndown Charts:

  • Compare progress across different teams or components of your project.
  • Track high-priority issues separately from the overall project burndown.
  • Analyze how different categories of issues (e.g., bugs vs. features) are progressing.
  • Create a burndown for a specific epic or feature set within a larger project to understand how that's contributing to the overall project.

  You can add up to 5 additional burndowns, allowing for comprehensive tracking and comparison of various aspects of your project.

• Start Date: The date from which the chart should start.

• End Date: Sets a minimum end date for the chart display and Show adds a checkered flag on the chart at the end date. This is particularly useful when:

  • You want to ensure the chart extends to a specific future date (like a planned release date)
  • You're using the Predict End Date feature and need to extend the chart beyond the automatic 50% extension limit
  • You can toggle whether to show the End Date line on the chart using the "Show" toggle next to the End Date field. If the Show is turned off, the End Date line will not be displayed on the chart, but the chart will still extend to the End Date and the End Date value will be shown in the chart legend.

• Max Initial Chart Date: Sets the maximum chart X value that is displayed when the chart is loaded. Warnings will display in the chart Configure view and the Chart subtitle if the selected date is in the past as that will result in initial data being displayed as truncated. Zoom out to see more data beyond this date. Reset zoom will utilize this value as the maximum X date for the chart.

• Days to Predict End Date: The number of days to predict the end date based on current progress. The prediction is only completed for the Primary Burndown and uses a least squares fit method to predict the end date.

Resource Management - aka "The Red Line"

• Budget in Story Points or Days/Hours: The total budget for the project and is rendered as a dashed line on the chart. It is used as a guideline for planning scope when trying to determine which issues to include in the burndown's scope. For time-based burndowns, the budget can be entered in either days or hours depending on your selected time unit, and will be automatically converted if you switch between units (using 8 hours = 1 day).

• Plan Anchor Date: Set a date to anchor your plan (date when your plan will be set or is set). This date is used to determine "The Red Line" (Resource Model burndown line) by anchoring the Resource Model to the Primary Burndown on this date. NOTE: the Plan Anchor Date is required when using a Resource Model and it must be on or after the earliest date in the Resource Model.

• Discovered Work %: The percentage of additional work expected to be discovered during the burndown's scope. The Resource Model is anchored at the Plan Anchor Date and then shifted up/down by this percentage of the Primary Burndown's value on that date.

• Resource Model Error Channel %: The expected percentage of error in resource estimates, which is used to draw error bars around the resource model and is determined based on the Resource Model Model Y value on the Plan Anchor Date.

• Resource Model: Define available resources over time. The Resource Model allows you to specify how your team's capacity changes throughout the project, which helps in creating more accurate burndown projections. The model differs slightly depending on whether you're using a time-based or story point-based burndown.

  Story Point-Based Burndowns:

  • Resources are defined in terms of the number of FTEs and their velocity (story points per week).
  • For each entry in the Resource Model, you specify:
    1. Start Date: When this resource allocation begins.
    2. Number of Resources: The number of FTEs working on the project.
    3. Weekly Velocity: The number of story points this team can complete per week.
  • Example: "From August 15, we have 5 FTEs with a velocity of 30 story points per week"

  Time-Based Burndowns:

  • Resources are defined in terms of Full-Time Equivalents (FTEs) and their utilization rate.
  • For each entry in the Resource Model, you specify:
    1. Start Date: When this resource allocation begins.
    2. Number of Resources: The number of FTEs working on the project.
    3. Utilization Rate: The percentage of time these resources are dedicated to the project (e.g., 80% if they're also working on other projects). NOTE: our experience suggests that 60% is a good utilization rate assumption.
  • Example: "From July 1, we have 3 FTEs at 80% utilization"

  In both cases, you can add multiple entries to reflect changes in your team's capacity over time. This could include:

  • Team members joining or leaving the project
  • Changes in team velocity as they become more familiar with the project
  • Planned time off or reduced capacity during holidays

  The Resource Model is used to calculate the ideal burndown line -- aka "The Red Line" -- helping you visualize whether your project is on track based on your team's capacity.

Milestones

• This feature allows you to mark significant events or deadlines directly on your chart as a vertical dashed line with an optional label.

  To add a milestone:

  1. Edit the first empty row in the Milestones table.
  2. Optionally, provide a label for the milestone (e.g., "Beta Release" or "New Feature Demo").
  3. Set the date when the milestone occurs.
  4. Choose a custom color for the milestone line.

  Note:

  • Up to 10 Milestones can be displayed.
  • Milestones are displayed in the chart's legend and can be individually toggled on and off.

  Benefits of using Milestones:

  • Visualize key project dates alongside your burndown progress
  • Quickly assess whether your current trajectory will meet important deadlines
  • Highlight significant events for stakeholders viewing the dashboard

  Milestones appear as vertical lines on your chart with their labels displayed.

Advanced Settings

• Chart Time Zone: Select the time zone for all date calculations (when creating a new burndown, it defaults to browser's time zone). The selected time zone is shown in the chart subtitle for clarity. The chart will be displayed as if the user is in this time zone irrespective of the users's actual time zone. This feature allows users working in different time zones to view the same exact chart. If you are working in a team that is distributed across multiple time zones that have very different working hours, consider creating two instances of the burndown chart (by adding a widget for each time zone), one for each time zone. This will allow users to view the chart in their local time zone and is especially helpful when using the Analyze Burndown Changes feature where the date of the change is important.
• Story Point Field (to override the Story Points field and only applicable to Story Points burndowns): The custom field ID for story points (e.g., "customfield_10041") and it's highly likely that your Story Point field has a different custom field ID. To find the custom field ID, go to Settings->Issues->Custom Fields and find the field with the name Story Points, then click on the field. In the dialog that appears, click Edit details. The custom field ID is the last number in the URL formatted as a number -- e.g., 10041. When overriding the field, the field name must be formatted as a string -- e.g., "customfield_10041".
• Make it Fun: This will add some playful visual elements to the burndown chart. This is purely for fun and has no impact on the burndown calculations. Have fun finding all the easter eggs!
• Enable Debug Mode for Troubleshooting: This will log additional information to the browser console to help troubleshoot issues. Make sure to disable this when you're done troubleshooting. Support may request that you enable this and provide some logging from the console.
• Clear Cache: This will clear cached data for the current widget scope. Save or Update preview requests fresh chart data without first clearing the cache. NOTE: the next calculation will create new cache.

4. Understanding the Burndown Chart

The burndown chart displays:

• Primary Burndown (green lines): The burndown of the remaining story points or effort based on the issue selection determined by Filter source. With Dashboard only, it uses the supported Jira dashboard filters rather than the widget's own query.
• Additional Burndowns (dashed green lines): If you've added additional burndowns, they'll appear as dashed lines.
• Story Points Complete or Time Spent depending on Burndown Type (blue lines): The story points completed or time spent on issues based on the Primary Burndown's issue selection.
• Estimate Accuracy (yellow lines): The accuracy of your initial estimates over time and is tracked starting at the Plan Anchor date.
  • For Story Points, this is any increase in the story points after the Plan Anchor date.
  • For Time-Based, starting on the Plan Anchor date, this is the sum of the remaining estimate (green burndowns) and the time spent (blue burndowns). The way to think about this is that if this line is has an increasing slope, that means the project's scope is increasing at a faster rate than the time spent, which means work is being discovered or scope is being added to the project. And the opposite holds as well -- if the line is decreasing, the project's scope is decreasing at a faster rate than the time spent.
• Resource Model: The ideal progress based on your resource model. When your Primary Burndown is not following to "The Red Line" (Resource Model), your project is likely off track.
• Plan Anchor: date when the plan is set or will be set. This date is used to determine "The Red Line" (Resource Model burndown line) and is labeled with the text "Plan Anchor". The "Max Scope" line is also labeled, which is the maximum scope of the project based on the Resource Model and discovered work percentage.
• End Date Line: A vertical black line showing your target completion date (if specified and enabled).
• Milestones: Vertical lines marking important dates in your project, with custom labels and colors.

Key features:

• Hover over data points to see detailed information.
• Use the zoom and pan features to focus on specific date ranges.
  • Zoom on the chart by clicking and dragging. The zoom will only occur in the x-axis.
  • To zoom the Y axis, move your mouse over the Y axis labels and scroll the mouse wheel.
• The "Reset Zoom" button returns the chart to its initial date range. If Max Initial Chart Date is set, that date is used as the maximum X date when resetting zoom.
• To pan the chart, hold down the CTRL key (on Windows/Linux) or CMD key (on Mac) and left click and drag the mouse.
• Open JQL Query: Click on the filter icon to open the widget's configured Jira filter or JQL query in Jira's issue navigator in a new tab. This is the widget query, so review dashboard filter selections separately when using Dashboard AND'd with widget Filter/JQL. Dashboard only does not use the widget query.
• Show/hide all buttons to toggle the visibility of all data sets.
• Download the chart as a PNG image by clicking on the picture icon.
• Download all series data as a CSV file by clicking on the download icon.
• Time Unit Toggle: only for time-based burndowns switch between displaying time in days (8hrs/day) or hours using the time unit toggle button in the chart toolbar. This toggle affects only the display and doesn't change your saved configuration.
• Expand Chart: Click the expand icon in the chart toolbar to view the chart and Analyze Burndown Changes table in fullscreen. This uses the displayed result rather than starting another backend calculation. Close the fullscreen view to return to the dashboard.
• Dashboard Filter Cautions: A yellow caution icon indicates that one or more dashboard filters were not applied. Click it to review the fields or data sources before interpreting the chart.
• Clear Cache: Clear the data cached in Atlassian's cloud for the current widget scope. Cached results are separated by viewer and issue-selection scope; clearing the cache also removes the retained result for the current refresh. NOTE: the next calculation will create new cache.

5. Using the Changelog Table

Below the chart, you'll find the Analyze Burndown Changes section:

1. The table is minimized by default to provide more space for the chart.
2. Click the "Show" button next to the "Analyze Burndown Changes" heading to expand the table.
3. Click "Hide" to collapse the table when you're done analyzing changes.
4. Use the dropdown to select different burndown data sets.
5. The table shows changes in story points or time estimates for each issue. NOTE: these are the aggregate changes on that date for each issue.
6. Click on an issue key to open it in Jira.
7. Download all series data as a CSV file by clicking on the download icon.
8. Sort the table by clicking on column headers.
9. Use the date filters to focus on specific time periods.
10. Click the synchronize filter button to update the table's date range filter to match the chart's current x-axis view.

6. Tips

• Use Dashboard only when you want the chart to follow supported Jira dashboard filters, or Widget only when you want a fixed Jira filter or JQL scope that is independent of dashboard selections.
• If your dashboard has many fields, start with one supported Jira filter, such as Space name, and add selections as needed. Keep the issue selection focused; selecting many projects or All can create a large burndown calculation.
• Use Update preview to review several configuration changes together before saving the widget. The Preview is out of date message means the chart has not yet received your latest form changes.
• In the configuration panel, you can click on the JQL query field's "Open in Jira" button to view the widget query in Jira's issue navigator. When using dashboard filters, review those selections separately.
• For time-based burndowns, toggle between days and hours using the time unit button in the chart toolbar to view your data in the most appropriate unit.
• Collapse the Analyze Burndown Changes table when you want to focus on the chart visualization.

7. Administrator Functions

Clearing the Site-Wide Cache

Jira administrators can clear the site-wide Jira change history cache for the Red Line Burndown app:

1. Navigate to the Jira Administration Settings page (gear in the top right corner).
2. Go to Apps.
3. Find the "Red Line Burndown" app in the list on the left sidebar and click on it.
4. Click the "Clear Red Line Burndown Sitewide Cache" button.
5. A confirmation message will appear at the bottom of the page when the cache clearing process is complete.

This operation:

• Clears cached Jira change histories across dashboard widgets for all users
• Causes the next calculation to rebuild those cached histories. Reload the dashboard, save the widget, or use Update preview to request fresh chart data after clearing the cache.
• Does NOT delete any user configuration data

Manually Running Weekly Cleanup Task

Administrators can also manually trigger the weekly cleanup task:

1. Navigate to the Jira Administration Settings page (gear in the top right corner).
2. Go to Apps.
3. Find the "Red Line Burndown" app in the list on the left sidebar and click on it.
4. Click the "Run Weekly Cleanup Task" button.
5. This task removes unused data from the cache for burndowns that haven't been accessed in 30 days and other transient per request data.
6. The task runs automatically every week, but can be manually triggered if needed.
7. This operation does NOT delete any user configuration data.
8. The task runs in the background, and you may leave the page after initiating it.

8. Troubleshooting

• If the chart doesn't load, check your JQL query and ensure it returns results. When using Dashboard only, check that a supported Jira dashboard filter is selected instead. The widget's own JQL is not used in that mode.
• If the widget asks you to save the widget and dashboard, finish adding and saving it before trying to display the burndown.
• If the chart shows a yellow caution icon, open it to see which dashboard filters were not applied. The Date and Request resolver delegator dashboard fields and non-Jira data sources are not supported. A caution does not mean the remaining supported filters were ignored.
• If the chart does not match another widget, compare their data sources and filters. Check the caution icon and the Filter source setting. Also note that Work item completed date and Work item resolution date both use JQL resolved in the Red Line Burndown.
• If the chart says Preview is out of date, select Update preview or save the widget. Editing the form alone does not refresh the chart.
• Reloading the dashboard fetches current Jira data, even if the previous calculation just finished. Opening the configuration panel displays the last successful matching result while it remains retained; it does not disappear from the edit preview after five minutes. If no matching result is available, use Update preview or Save. Update preview and Save request fresh data. Expanding the chart to fullscreen displays the result already on screen.
• Checking for a saved chart is a result lookup, not confirmation that a new calculation was queued. With Debug Mode enabled, the browser console reports either Reused result; no calculation queued or New calculation queued with a task ID.
• For performance issues, try narrowing your date range or simplifying your JQL query.
• If data seems incorrect, verify your story point field and start date in the configuration.
• If you're experiencing issues with cached data, you can:
  • Clear the widget instance cache using the trash icon in the chart toolbar.
  • Save or Update preview requests fresh chart data without first clearing the cache.
  • For more persistent issues, contact your Jira administrator to clear the site-wide cache (see Administrator Functions above).

9. Support

If you encounter any issues, we may ask you to share the widget's configuration with a screenshot. Additionally we may ask you to check your webbrowser's console for any errors.

For additional support, please contact your Jira administrator or Crimsalytics for support for The Red Line Burndown Widget support team.

Classic Jira Dashboards

1. Introduction

The Redline Burndown Gadget is a powerful tool for tracking project progress and estimating completion dates. It provides a visual representation of work completed over time, helping teams to monitor their progress and identify potential delays or issues.

This guide covers the Red Line Burndown gadget on classic Jira dashboards. It uses a saved Jira filter or JQL query to define the issues included in the chart.

2. Adding the Gadget to Your Dashboard

1. Navigate to your Jira dashboard.
2. Click on "Add gadget" or "Edit dashboard" (depending on your Jira version).
3. Search for "Crimsalytics Red Line Burndown" in the gadget directory.
4. Click "Add" to add the gadget to your dashboard.

3. Configuring the Gadget

After adding the gadget, you'll need to configure the required fields at a minimum, which are:

1. Click on the 3 dots in the upper right hand corner of the gadget and then click on "Configure" to open the configuration panel.
2. Set the following required fields (NOTE: Items in the Configuration pane with an "*" are required.)
   • Burndown Type
   • Select a Jira filter or enter JQL
   • Start Date
   • Chart Time Zone (in the Advanced Settings section at the bottom and automatically defaults to your time zone)
3. For a simple chart, you can stop here and click "Save". However, there are many additional configuration options available to customize the chart to your needs. See below documentation for more details on each section.

The gadget uses its saved Jira filter or JQL query to select issues. After making changes, click Save in the gadget's configuration form to apply them. Use Cancel to discard unsaved changes.

Configuring in Fullscreen

Click Configure in fullscreen in the top of the configuration panel for more room to edit the settings and tables. Click Apply changes to return the changes to the original configuration form, then save there to finish. NOTE: In full screen configuration edit mode, clicking Apply changes by itself does not save the gadget.

Burndown Settings

• Burndown Type: Choose between "Story Points" or "Time-Based" burndown.

  • Story Points: Jira's built-in Story Point field is actually a custom field with the name Story Points. This is used to track progress based on story point estimates. If necessary, you can override the default field by setting the name of the custom Story Point Field (e.g., "customfield_10041"). See below for further details on overriding this field. An error message will appear if the field is not found.
  • Time-Based: Uses Jira's built-in time tracking fields (Original Estimate, Remaining Estimate, and Time Spent) to calculate progress. - When using Time-Based, you need to make sure that you either set the remaining estimate to the proper value (usually 0) when the status is changed to a "Done" state or you need to configure Jira to automatically set the remaining estimate to 0 when the status is changed to a "Done" state. Here's a link to an Atlassian article on how to configure this: https://confluence.atlassian.com/jirakb/set-remaining-estimate-to-0-on-post-function-304579031.html - For Time-Based burndowns, you can also select your preferred time unit (Days or Hours) for display. This affects how time values are shown in the chart and table. The system uses a standard conversion of 8 hours = 1 day.

• Query Mode: Choose between "Filter" or "JQL" to define which issues to include in the burndown.

  • Filter: Select from your saved Jira filters. The filter's JQL will be used for the burndown calculation.
    • NOTE: if a filter is selected and a Configuration Error states Changelog is empty. Please check your JQL Query in the gadget configuration and test that it returns issues in the Jira Filters page. Please update the gadget configuration and try again.
    • First open the filter to make sure that there are Jira Issues returned by the filter.
      • If the filter returns 0 issues, then fix the filter.
      • If the filter returns at least one issue, then it's likely a permissions issue. On the Jira Filters page, edit the filter and under Viewers select My organization, press Add and hit Save. This will make the filter visible to all users in your organization including the Red Line Burndown gadget. After doing so, refresh the dashboard and the error should be resolved.
  • JQL: Enter a custom JQL query directly.

• Additional Burndown Charts: Add extra burndowns based on specific criteria. This feature allows you to create and compare multiple burndown charts within the same gadget. Each additional burndown can have its own JQL query, enabling you to track different subsets of issues or teams.

  To add an additional burndown:

  1. Click in the first empty row in the Additional Burndown Charts section.
  2. Provide a name for the new burndown (e.g., "Team A Burndown" or "High Priority Issues" or "Added Scope" or "Bugs").
  3. Enter a JQL query to define which issues should be included in this burndown. NOTE: this filter will be ANDed with the primary issue selection to create a subset of issues for this burndown.
  4. The burndown will automatically pick a line style for the burndown to distinguish it from all the other burndowns.

  Benefits of using Additional Burndown Charts:

  • Compare progress across different teams or components of your project.
  • Track high-priority issues separately from the overall project burndown.
  • Analyze how different categories of issues (e.g., bugs vs. features) are progressing.
  • Create a burndown for a specific epic or feature set within a larger project to understand how that's contributing to the overall project.

  You can add up to 5 additional burndowns, allowing for comprehensive tracking and comparison of various aspects of your project.

• Start Date: The date from which the chart should start.

• End Date: Sets a minimum end date for the chart display and Show adds a checkered flag on the chart at the end date. This is particularly useful when:

  • You want to ensure the chart extends to a specific future date (like a planned release date)
  • You're using the Predict End Date feature and need to extend the chart beyond the automatic 50% extension limit
  • You can toggle whether to show the End Date line on the chart using the "Show" toggle next to the End Date field. If the Show is turned off, the End Date line will not be displayed on the chart, but the chart will still extend to the End Date and the End Date value will be shown in the chart legend.

• Max Initial Chart Date: Sets the maximum chart X value that is displayed when the chart is loaded. Warnings will display in the chart Configure view and the Chart subtitle if the selected date is in the past as that will result in initial data being displayed as truncated. Zoom out to see more data beyond this date. Reset zoom will utilize this value as the maximum X date for the chart.

• Days to Predict End Date: The number of days to predict the end date based on current progress. The prediction is only completed for the Primary Burndown and uses a least squares fit method to predict the end date.

Resource Management - aka "The Red Line"

• Budget in Story Points or Days/Hours: The total budget for the project and is rendered as a dashed line on the chart. It is used as a guideline for planning scope when trying to determine which issues to include in the burndown's scope. For time-based burndowns, the budget can be entered in either days or hours depending on your selected time unit, and will be automatically converted if you switch between units (using 8 hours = 1 day).

• Plan Anchor Date: Set a date to anchor your plan (date when your plan will be set or is set). This date is used to determine "The Red Line" (Resource Model burndown line) by anchoring the Resource Model to the Primary Burndown on this date. NOTE: the Plan Anchor Date is required when using a Resource Model and it must be on or after the earliest date in the Resource Model.

• Discovered Work %: The percentage of additional work expected to be discovered during the burndown's scope. The Resource Model is anchored at the Plan Anchor Date and then shifted up/down by this percentage of the Primary Burndown's value on that date.

• Resource Model Error Channel %: The expected percentage of error in resource estimates, which is used to draw error bars around the resource model and is determined based on the Resource Model Model Y value on the Plan Anchor Date.

• Resource Model: Define available resources over time. The Resource Model allows you to specify how your team's capacity changes throughout the project, which helps in creating more accurate burndown projections. The model differs slightly depending on whether you're using a time-based or story point-based burndown.

  Story Point-Based Burndowns:

  • Resources are defined in terms of the number of FTEs and their velocity (story points per week).
  • For each entry in the Resource Model, you specify:
    1. Start Date: When this resource allocation begins.
    2. Number of Resources: The number of FTEs working on the project.
    3. Weekly Velocity: The number of story points this team can complete per week.
  • Example: "From August 15, we have 5 FTEs with a velocity of 30 story points per week"

  Time-Based Burndowns:

  • Resources are defined in terms of Full-Time Equivalents (FTEs) and their utilization rate.
  • For each entry in the Resource Model, you specify:
    1. Start Date: When this resource allocation begins.
    2. Number of Resources: The number of FTEs working on the project.
    3. Utilization Rate: The percentage of time these resources are dedicated to the project (e.g., 80% if they're also working on other projects). NOTE: our experience suggests that 60% is a good utilization rate assumption.
  • Example: "From July 1, we have 3 FTEs at 80% utilization"

  In both cases, you can add multiple entries to reflect changes in your team's capacity over time. This could include:

  • Team members joining or leaving the project
  • Changes in team velocity as they become more familiar with the project
  • Planned time off or reduced capacity during holidays

  The Resource Model is used to calculate the ideal burndown line -- aka "The Red Line" -- helping you visualize whether your project is on track based on your team's capacity.

Milestones

• This feature allows you to mark significant events or deadlines directly on your chart as a vertical dashed line with an optional label.

  To add a milestone:

  1. Edit the first empty row in the Milestones table.
  2. Optionally, provide a label for the milestone (e.g., "Beta Release" or "New Feature Demo").
  3. Set the date when the milestone occurs.
  4. Choose a custom color for the milestone line.

  Note:

  • Up to 10 Milestones can be displayed.
  • Milestones are displayed in the chart's legend and can be individually toggled on and off.

  Benefits of using Milestones:

  • Visualize key project dates alongside your burndown progress
  • Quickly assess whether your current trajectory will meet important deadlines
  • Highlight significant events for stakeholders viewing the dashboard

  Milestones appear as vertical lines on your chart with their labels displayed.

Advanced Settings

• Chart Time Zone: Select the time zone for all date calculations (when creating a new burndown, it defaults to browser's time zone). The selected time zone is shown in the chart subtitle for clarity. The chart will be displayed as if the user is in this time zone irrespective of the users's actual time zone. This feature allows users working in different time zones to view the same exact chart. If you are working in a team that is distributed across multiple time zones that have very different working hours, consider creating two instances of the burndown chart (by clicking on the 3 dots in the upper right hand corner of the gadget and then clicking on "Duplicate"), one for each time zone. This will allow users to view the chart in their local time zone and is especially helpful when using the Analyze Burndown Changes feature where the date of the change is important.
• Story Point Field (to override the Story Points field and only applicable to Story Points burndowns): The custom field ID for story points (e.g., "customfield_10041") and it's highly likely that your Story Point field has a different custom field ID. To find the custom field ID, go to Settings->Issues->Custom Fields and find the field with the name Story Points, then click on the field. In the dialog that appears, click Edit details. The custom field ID is the last number in the URL formatted as a number -- e.g., 10041. When overriding the field, the field name must be formatted as a string -- e.g., "customfield_10041".
• Make it Fun: This will add some playful visual elements to the burndown chart. This is purely for fun and has no impact on the burndown calculations. Have fun finding all the easter eggs!
• Enable Debug Mode for Troubleshooting: This will log additional information to the browser console to help troubleshoot issues. Make sure to disable this when you're done troubleshooting. Support may request that you enable this and provide some logging from the console.
• Clear Cache: This will clear the cached data for the gadget. This is useful if you've made changes to the configuration and want to force the gadget to refresh the data. NOTE: the next refresh will create new cache.

4. Understanding the Burndown Chart

The burndown chart displays:

• Primary Burndown (green lines): The burndown of the remaining story points or effort based on your Primary JQL query.
• Additional Burndowns (dashed green lines): If you've added additional burndowns, they'll appear as dashed lines.
• Story Points Complete or Time Spent depending on Burndown Type (blue lines): The story points completed or time spent on issues based on your Primary JQL query.
• Estimate Accuracy (yellow lines): The accuracy of your initial estimates over time and is tracked starting at the Plan Anchor date.
  • For Story Points, this is any increase in the story points after the Plan Anchor date.
  • For Time-Based, starting on the Plan Anchor date, this is the sum of the remaining estimate (green burndowns) and the time spent (blue burndowns). The way to think about this is that if this line is has an increasing slope, that means the project's scope is increasing at a faster rate than the time spent, which means work is being discovered or scope is being added to the project. And the opposite holds as well -- if the line is decreasing, the project's scope is decreasing at a faster rate than the time spent.
• Resource Model: The ideal progress based on your resource model. When your Primary Burndown is not following to "The Red Line" (Resource Model), your project is likely off track.
• Plan Anchor: date when the plan is set or will be set. This date is used to determine "The Red Line" (Resource Model burndown line) and is labeled with the text "Plan Anchor". The "Max Scope" line is also labeled, which is the maximum scope of the project based on the Resource Model and discovered work percentage.
• End Date Line: A vertical black line showing your target completion date (if specified and enabled).
• Milestones: Vertical lines marking important dates in your project, with custom labels and colors.

Key features:

• Hover over data points to see detailed information.
• Use the zoom and pan features to focus on specific date ranges.
  • Zoom on the chart by clicking and dragging. The zoom will only occur in the x-axis.
  • To zoom the Y axis, move your mouse over the Y axis labels and scroll the mouse wheel.
• The "Reset Zoom" button returns the chart to its initial date range. If Max Initial Chart Date is set, that date is used as the maximum X date when resetting zoom.
• To pan the chart, hold down the CTRL key (on Windows/Linux) or CMD key (on Mac) and left click and drag the mouse.
• Open JQL Query: Click on the filter icon to open your primary JQL query in Jira's issue navigator in a new tab.
• Show/hide all buttons to toggle the visibility of all data sets.
• Download the chart as a PNG image by clicking on the picture icon.
• Download all series data as a CSV file by clicking on the download icon.
• Time Unit Toggle: only for time-based burndowns switch between displaying time in days (8hrs/day) or hours using the time unit toggle button in the chart toolbar. This toggle affects only the display and doesn't change your saved configuration.
• Expand Chart: Click the expand icon in the chart toolbar to view the chart and Analyze Burndown Changes table in fullscreen. This uses the displayed result rather than starting another backend calculation. Close the fullscreen view to return to the dashboard.
• Clear Cache: Clear the data cached in Atlassian's cloud for this gadget on this dashboard. The instance cache is shared by users of the gadget. NOTE: the next calculation will create new cache.

5. Using the Changelog Table

Below the chart, you'll find the Analyze Burndown Changes section:

1. The table is minimized by default to provide more space for the chart.
2. Click the "Show" button next to the "Analyze Burndown Changes" heading to expand the table.
3. Click "Hide" to collapse the table when you're done analyzing changes.
4. Use the dropdown to select different burndown data sets.
5. The table shows changes in story points or time estimates for each issue. NOTE: these are the aggregate changes on that date for each issue.
6. Click on an issue key to open it in Jira.
7. Download all series data as a CSV file by clicking on the download icon.
8. Sort the table by clicking on column headers.
9. Use the date filters to focus on specific time periods.
10. Click the synchronize filter button to update the table's date range filter to match the chart's current x-axis view.

6. Tips

• Change the name of the gadget by clicking on the text Red Line Burndown at the top of the gadget's display. This can be used as a chart title to explain the data presented in the chart.
• Once the burndown is configured the way you want, you can easily duplicate the configuration by clicking on the 3 dots in the upper right hand corner of the gadget and then clicking on "Duplicate".
• In the configuration panel, you can click on the JQL query field's "Open in Jira" button to view the results of your query in Jira's issue navigator.
• For time-based burndowns, toggle between days and hours using the time unit button in the chart toolbar to view your data in the most appropriate unit.
• Collapse the Analyze Burndown Changes table when you want to focus on the chart visualization.

7. Administrator Functions

Clearing the Site-Wide Cache

Jira administrators can clear the site-wide cache for the Red Line Burndown gadget, which affects all instances of the gadget across all dashboards:

1. Navigate to the Jira Administration Settings page (gear in the top right corner).
2. Go to Apps.
3. Find the "Red Line Burndown" app in the list on the left sidebar and click on it.
4. Click the "Clear Red Line Burndown Sitewide Cache" button.
5. A confirmation message will appear at the bottom of the page when the cache clearing process is complete.

This operation:

• Clears cached Jira change histories across dashboard gadgets for all users
• Causes the next calculation to rebuild those cached histories.
• Does NOT delete any user configuration data

Manually Running Weekly Cleanup Task

Administrators can also manually trigger the weekly cleanup task:

1. Navigate to the Jira Administration Settings page (gear in the top right corner).
2. Go to Apps.
3. Find the "Red Line Burndown" app in the list on the left sidebar and click on it.
4. Click the "Run Weekly Cleanup Task" button.
5. This task removes unused data from the cache for burndowns that haven't been accessed in 30 days and other transient per request data.
6. The task runs automatically every week, but can be manually triggered if needed.
7. This operation does NOT delete any user configuration data.
8. The task runs in the background, and you may leave the page after initiating it.

8. Troubleshooting

• If the chart doesn't load, check your Jira filter or JQL query and ensure it returns results.
• For performance issues, try narrowing your date range or simplifying your JQL query.
• If data seems incorrect, verify your story point field and start date in the configuration.
• If you're experiencing issues with cached data, you can:
  • Clear the gadget instance cache using the trash icon in the chart toolbar.
  • For more persistent issues, contact your Jira administrator to clear the site-wide cache (see Administrator Functions above).

9. Support

If you encounter any issues, we may ask you to share the gadget's configuration with a screenshot. Additionally we may ask you to check your webbrowser's console for any errors.

For additional support, please contact your Jira administrator or Crimsalytics for support for The Red Line Burndown Gadget support team.

Version History / Release Notes

Atlassian controls the version numbers. Our first release was version 2.4.

v2.30 (November 1, 2026)

New Features:

• New Jira Dashboards: Added widget support alongside the existing classic dashboard gadget. New dashboard widgets support Jira data only, with Dashboard only, Dashboard AND widget Filter/JQL, and Widget only filter sources.
• Dashboard Filters: Supported Jira dashboard filters are translated to JQL. A caution icon identifies filters that could not be applied, including Date, Request resolver delegator, and non-Jira data sources.
• Fullscreen Views: Added fullscreen chart analysis and configuration for both dashboard types.
• Widget Title: Added a configurable title for new dashboard widgets, shown above the chart and in fullscreen.

Enhancements:

• New dashboard editors reuse recent chart results while editing, with Update preview and a Preview is out of date indicator. Save, Update preview, and dashboard reloads fetch fresh Jira data.
• Split the manual into separate new and classic dashboard guides, including dashboard field-to-JQL mappings. Updated application libraries and build tooling.

Bug Fixes:

• Fixed chart date bounds during zooming and preserved zoom when showing or hiding Analyze Burndown Changes.
• Improved chart controls and axis labels in smaller views, configuration tooltips, milestone editing, and fireworks cleanup.
• Fixed new widget setup before the dashboard is saved and improved configuration validation and error handling.

v2.29 (May 1, 2026)

New Features:

• Added Max Initial Chart Date to allow users to set the maximum X value on the chart when it initially loads. See above user documentation for more details.

Bug Fixes:

• Broke out the tooltips for the Start Date, End Date and Max Initial Chart Dates

v2.28 (April 26, 2026)

Upgraded to Node.js 24

Bug Fixes:

• Fix heading colors in Configure view when in dark mode

Known Issues:

If dashboards won't load properly and show an error message like the below, try clearing the cache for Jira. If you're using Chrome, then open Developer tools (F12 or Ctrol+Shift+i Windows; Cmd+Option+I on Mac), click the Network tab, then check the box Disable cache. Reload the page and then re-enable caching.

503
Code: Slow Down
Message: Please reduce your request rate.

v2.27 (January 17, 2026)

Bug Fixes:

• Improve Jira API rate limit handling as it appears that Atlassian is now more aggresively rate limiting API calls per https://developer.atlassian.com/cloud/jira/platform/rate-limiting/

v2.25 & v2.26 (December 5, 2025)

Changes in this version require clearing the site cache using these instructions.

Bug Fixes:

• Fix logging issue in time mode
• Time based and story points based mode: if a Jira issue had more than 40 history records, the burndown calculation was only including the 40 most recent events irrespective of the field impacted. The fix is to fetch the entire changelog history separately for all issues.
• Story Points mode: if a Jira configuration had multiple Story Points fields defined with the name "Story Points" and a user modified both fields for a specific issue, then the burndown calculation would be impacted by changes to both fields, which would result in an incorrect burndown just for that issue. See above for cache clearing instructions. The new version utilizes the rest/api/3/changelog/bulkfetch api to retrieve the entire changelog history for all issues and then filter the results. Some Jira instances may not include a fieldId within the changelog history for custom fields. In this case, the fieldId will be null. The new version handles this case by also checking the field name and type to identify the correct field.
• Story Points mode: if a Jira issue transitioned to closed and then reopened on the same day, the story points remaining for that issue would remain at zero instead of reflecting the Story Points value when the issue was reopened.
• Fixed bug when the primary burndown's JQL had several OR clauses in the JQL, the additional JQL's were not being ANDed correctly with the primary JQL. This has been fixed by wrapping the primary JQL in parentheses before ANDing it with the additional JQL.
• Fixed bug where JQL that had greater than or less than operators would not open properly when clicking on the "Open in Jira" button on the chart's toolbar.
• Sped up the loading of filters in the Configuration view.

v2.23 & 2.24 (December 3, 2025)

• v2.24 reverted changes in v2.23.

v2.22 (November 21, 2025)

Enhancements:

• Time zone selector in the edit view now supports searching for a time zone using text contains logic instead of text starts with logic.

Bug Fixes:

• Fixed bug where chart did not properly display information based on the selected time zone when the viewed from a different time zone. One side effect of the bug was that the Plan Anchor Date being shifted left by 1 day and the tooltip dates shifted by 2 dates left.
• Fixed bug in Story Point mode where the Estimate Accuracy series had two points on the Plan Anchor Date.

v2.21 (September 23, 2025)

Enhancements:

• Improved tooltip on the resource model to include the overall discovered work (change in the yellow line from the Plan Anchor Date to today) and enhanced the format of the tooltips to display the actual velocity or utilization for the associated resource model point immediately after the plan values.
• Improved tooltip for the Estimate Accuracy series to include the actual discovered work on the date of the tooltip, which is defined by the change in the Estimate Accuracy line from the Plan Anchor Date to the date of the tooltip.

v2.20 (September 18, 2025)

Enhancements:

• Reorderd the Configure view to group like inputs together. Updated documentation to align with streamlined layout.

Bug Fixes:

• Renamed the Utilization Error % field to Resource Model Error Channel % to better reflect it's purpose. Updated documentation to align.
• If the Resource Model Error Channel % is large enough, the lower error channel of the resource model could start below zero, which resulted in an exception. This fix ensures the lower error channel never starts below zero.
• Fixed bug where the Resource Model Error Channel % was calculated based on the resource model line on the resource point closest to the Plan Anchor if it was not in the model. Now the error channel is calculated based on the resource model line on the Plan Anchor Date.
• In the Configure view, add validation of the Plan Anchor Date to ensure it's set when there's a resource model and is on or after the earliest date in the resource model. Validation is performed on Save and error messages are displayed above the Save button.
• Add user-defined Resource Model Error Channel % to the tooltip for the Resource Model series.

v2.19 (August 29, 2025)

Bug Fixes:

• Replaced deprecated Jira API search endpoint with valid endpoint
• Improved error message for Filter mode when filter permissions are not set correctly

v2.18 (July 27, 2025)

Bug Fixes:

• Fixed issues where chart would not render due to "Invalid Date" errors in prediction calculations when end date is in the past or missing

v2.17 (July 14, 2025)

Bug Fixes:

• Fixed bug associated with Make it Fun mode.

v2.16 (July 13, 2025)

New Features:

• Make it Fun: Added ability to enable a fun mode with some fun visualizations. This is purely for fun and has no impact on the burndown calculations.

Bug Fixes:

• Fixed bug introduced in v2.15 where the Y scale max value did not include the time-spent/story points burned or remaining time/story points.
• Improved server side task processing logging

v2.15 & v2.14 (June 28, 2025)

New Features:

• End Date Line: Added ability to display a vertical line at the project's target end date with a toggle to show/hide it
• Milestone Support: Added support for adding up to 10 milestones to mark important dates on the burndown chart
• Filter Selection: Added ability to select from saved Jira filters as an alternative to entering JQL queries
• UI Improvements: Enhanced layout and spacing in the configuration panel for better usability

Bug Fixes:

• Fixed bug where editing after a reordering Additional Burndowns or Milestones would not save the new order
• Fixed occasional off by one dates in the chart because of time zone issues
• Clean up tooltips to reduce duplicates and improve usability

v2.13 (June 25, 2025)

Bug Fixes:

• Mac Compatibility: Fixed chart panning functionality for Mac users by changing the modifier key from CTRL to CMD (Command key), which prevents conflicts with Mac's context menu.

v2.12 (June 14, 2025)

New Features:

• End Date Configuration: Added optional End Date field to configuration panel. This allows you to set a minimum end date for the chart display, which is particularly useful when using the Predict End Date feature to extend the chart range beyond the automatic 50% extension limit.

Bug Fixes:

• Time-based Burndowns ONLY: Fixed multiple minor issues affecting time-based calculations:
  • Fixed bug where remaining estimates could become negative during burndown calculations, ensuring values never go below zero
  • In rare instances, Jira's API does not return the remainingEstimateSeconds field in the timetracking data for an issue. This would result in the 'Analyze Burndown Changes' feature showing 0 for the 'Current Remaining Estimate' column. This has been fixed by using our calculated remaining estimate value in these cases.
  • Fixed bug where time spent logged on the creation date was not included in the burndown calculations.
  • NOTE: If you are using time-based calculations, you should clear the site cache using these instructions.
• Tooltip Improvements:
  • When in hours mode, fixed bug in chart tooltips shown when clicking on a row in the 'Analyze Burndown Changes' table showed values displayed in days instead of hours.
  • Add the '# of Days to Predict End Date' to the Predicted End Date series tooltip.

v2.11 (May 28, 2025)

Bug Fixes:

• Time-based Burndowns ONLY: Fixed bug where the remaining estimate computed by the burndown for a small subset of issues did not match the remaining estimate for Jira. In the prior versions, the original estimate was used to set the initial remaining estimate; however if the user changed the original estimate after initially setting it and did not update the remaining estimate to match, then the burndown would compute an inconsistent initial remaining estimate for the burndown -- meaning the final remaining estimate for that issue may not match the current remaining estimate field's value. This has been fixed by using the current remaining estimate as the initial remaining estimate and then adding the sum of the deltas (from the issue history) to the remaining estimate to get the original remaining estimate. This guarantees that the initial remaining estimate matches the current remaining estimate and preserves the integrity of the changelog especially when dealing with direct changes to the remaining estimate when, for example, scope increases or decreases and the time spent is not changed.
  • NOTE: If you are using time-based calculations, you should clear the site cache using these instructions.

v2.10 (May 25, 2025)

New Features

• Time Unit Configuration: Added a new configuration option to select the time unit (days or hours) for time-based burndowns.
• Added debug mode for troubleshooting. This can be enabled in the configuration page.

Bug Fixes

• Fixed bugs in text colors for theming support that affected both light and dark mode

v2.9 (May 24, 2025)

New Features

• Enhanced JQL Navigation:
  • On the burndown chart toolbar, added button to open primary JQL query results.
  • In the Configure page, added buttons to open JQL query results for the primary JQL query and each additional JQL query. NOTE: the additional JQL queries are ANDed with the primary JQL query to create a subset of issues for that Additional Burndown, which is exactly how the burndowns are calculated for these secondary data series.
• UI Improvements: Analyze burndown changes table is now hidden by default to simplify the user interface. To expand it, hit the Show button next to the "Analyze Burndown Changes" heading. To collapse it, hit the Hide button.
• Time Unit Toggle: In time-based burndowns, use the clock icon in the chart toolbar to switch the Y-axis between days and hours

Bug Fixes

• Time-based mode only - Fixed issue where time-based changelog was being overwritten when
  • multiple change histories occurred on the same date, and
  • a subsequent issue did not have any change history that just had an original estimate without any history affecting the worklog.
  • NOTE: If you are using time-based calculations, you should clear the site cache using these instructions.
• Story Point mode only - Fixed issue where the number of unestimated story points tasks was not being computed properly (checking against null instead of 0, as 0 is technically an estimate)

v2.8 (May 14, 2025)

Bug Fixes:

• Fix error message

v2.7 (April 20, 2025)

Bug Fixes:

• Upgrade forge libraries to address an error that was occassionally happening:

FetchError: request to https://stargate/forge/entities/graphql failed, reason: socket hang up
at ClientRequest.<anonymous> (webpack://jira-dashboard-gadget-custom-ui/node_modules/node-fetch/lib/index.mjs:1495:1)
at ClientRequest.emit (node:events:530:35)
at emitErrorEvent (node:_http_client:101:11)
at TLSSocket.socketCloseListener (node:_http_client:477:7)
at TLSSocket.emit (node:events:530:35)\n    at node:net:343:12
at TCP.done (node:_tls_wrap:648:7)

v2.6 (April 2, 2025)

Bug Fixes:

• Move asApp calls to get status map into async processing
• Fixed some frontend error handling & messages
• Eliminate scroll bars on the Analyze Burndown Changes table

v2.5 (March 1, 2025)

Features:

• Admin & Maintenance
  • Replaced App Configure page with Settings->Apps->sidebar admin page (Crimsalytics Red Line Burndown Admin)
  • Added button to run weekly maintenance tasks
  • Added button to clear site-wide cache
  • Implemented automatic weekly scheduled Forge Storage cleanup task

Infrastructure

• Improved mechanism for writing larger blocks of data to Forge Storage for caching burndown results with improved strategy for rate limits
• Improved cache clearing

Bug Fixes:

• Simplified and improved story points completed calculation (blue series) including only taking credit for completed points when the status changes to done. If the status moves back out of a done status, those points are removed from the points spent (blue series).
• Enhanced weekly velocity tooltip (purple series) to show 0.1 increment support
• Fixed CSV changelog export

v2.4 (January 17, 2025)

Initial release