Share via

How to create an Epic burndown chart using the Burndown Dashboard Widget in Azure Boards

Rupert Schmidtberg 0 Reputation points
2026-03-02T18:02:24.77+00:00

I need to create a burndown chart for an Epic which has child Features and User Stories. I've asked Copilot for help and the information it provided doesn't correspond to what I see on the configuration screen for the Burndown Widget (see Copilot results below). I need to Epic burndown to roll up the progress on the child Epics and Stories. Specifically, I don't see any "Rollup" options on the widget configuration screen as described by Copilot. I've done everything else exactly as described by Copilot.

How can I create the Epic burndown that I need?

---- Copilot instructions
Copilot

Reasoning completed in 1 step

Perfect—let’s walk through it step by step for your “Portfolio Mgmt” team with the Analytics Burndown widget, so it burns down Story Points rolled up from child Features and User Stories under an Epic.

Goal: Make the widget show/compute from Epics by enabling the Epic backlog for the team and configuring the widget to use the Epic backlog level + rollup.

Part A — Ensure the Epic backlog is enabled for the “Portfolio Mgmt” team

  1. In Azure DevOps, go to Project Settings (bottom-left gear).
  2. Select Teams → click Portfolio Mgmt.
  3. Click Team configuration.
  4. Open the Backlogs tab.
  5. Under Backlog levels, turn Epic → ON.
    • Also ensure Feature and Stories are ON (they usually are).
    1. (Optional) In Working with bugs, choose whether Bugs appear on the Stories backlog—doesn’t affect Epic burndown, but good to set consistently.
    2. Click Save (if a save button appears; some orgs auto-save).

Why this matters: The Analytics burndown can only roll up to parent levels that are enabled in the team’s backlog configuration. If Epic is disabled, the widget hides the rollup/descendant controls and can’t aggregate Epic → Feature → Story.

Part B — Confirm the iteration/timebox for the Epic

The Analytics Burndown must be scoped to an Iteration Path (timebox) even for an Epic.

You have two workable patterns:

  • Preferred (non-invasive): Assign the Epic to the timebox iteration (e.g., Portfolio\2026 Q2). Child work can remain in teams’ sprint iterations; the widget will roll up as long as the Epic is in the selected iteration hierarchy.
  • Alternative (more invasive): Assign all child Features/Stories to a shared planning iteration. This can conflict with team sprint boards, so use only if needed.

To check/set:

  1. Open the Epic you want to burn down.
  2. Verify the Iteration Path aligns with your timebox (e.g., a Quarter or PI node).
  3. If your portfolio uses quarterly buckets, ensure the Epic is assigned to the correct quarter (e.g., Portfolio Mgmt\2026 Q2).

Part C — Configure the Burndown (Analytics) widget

Go to your Dashboard where you added Burndown (Analytics).

Click the wrench (configure) icon on the widget.

Set these key options (names can vary slightly by UI version):

Scope / Team

  • Team: Portfolio Mgmt (OK if this rolls up across teams)

Timebox

  - **Iteration**: Select the **timebox iteration** that contains the Epic (e.g., your Quarter/PI node).
  
  **Backlog level**
  
     - Choose **Epic**.
     
     > This is critical—choosing Epic unlocks the descendant rollup behavior.
     
     **Measure**
     
        - **Burndown by** → **Sum of a field** → **Story Points**.
        
        **Rollup**
        
           - Turn ON:
           
                 - **Include descendant items** (or **Include child items in calculation**)
                 
                       - **Roll up values from child work items**
                       
                          - If you see a control like **“Progress is calculated by”**, set it to **Descendants (rollup)**.
                          
                          **Completion logic**
                          
                             - **Completed when** → **State category = Completed** (Adjust if your workflow uses custom Done states/categories.)
                             
                             **(Optional) Filter to a specific Epic**
                             
                                - If the widget version supports a filter:
                                
                                      - **Field**: `Parent` (or **Ancestor**)
                                      
                                            - **Operator**: `=`
                                            
                                                  - **Value**: your **Epic ID = 1** If you don’t see a filter, the Epic context will come from the **Backlog level (Epic)** + **Iteration** selection. In that case, make sure only the Epic(s) you want are in that iteration during the timebox.
                                                  
                                                  **Save** the widget configuration.

Part D — Validate data shows as expected

After saving, check:

  • You see a declining line for Story Points remaining over the timebox.
  • If the line is flat at zero:
  • Verify child Features/Stories have Story Points (non-empty).
  • Ensure the Epic is in the selected Iteration.
  • Ensure Epic backlog is enabled (Part A) and Backlog level = Epic in the widget.
  • Confirm the rollup/descendant options are ON.
    • Check state categories—if your Done states aren’t mapped to Completed, the burndown won’t decrement. You may need to choose specific states instead of category.Copilot Reasoning completed in 1 step Perfect—let’s walk through it step by step for your “Portfolio Mgmt” team with the Analytics Burndown widget, so it burns down Story Points rolled up from child Features and User Stories under an Epic.

      Goal: Make the widget show/compute from Epics by enabling the Epic backlog for the team and configuring the widget to use the Epic backlog level + rollup.

      Part A — Ensure the Epic backlog is enabled for the “Portfolio Mgmt” team

      1. In Azure DevOps, go to Project Settings (bottom-left gear).
      2. Select Teams → click Portfolio Mgmt.
      3. Click Team configuration.
      4. Open the Backlogs tab.
      5. Under Backlog levels, turn Epic → ON.
        • Also ensure Feature and Stories are ON (they usually are).
      6. (Optional) In Working with bugs, choose whether Bugs appear on the Stories backlog—doesn’t affect Epic burndown, but good to set consistently.
      7. Click Save (if a save button appears; some orgs auto-save).

      Why this matters: The Analytics burndown can only roll up to parent levels that are enabled in the team’s backlog configuration. If Epic is disabled, the widget hides the rollup/descendant controls and can’t aggregate Epic → Feature → Story.

      Part B — Confirm the iteration/timebox for the Epic

      The Analytics Burndown must be scoped to an Iteration Path (timebox) even for an Epic. You have two workable patterns:
      • Preferred (non-invasive): Assign the Epic to the timebox iteration (e.g., Portfolio\2026 Q2). Child work can remain in teams’ sprint iterations; the widget will roll up as long as the Epic is in the selected iteration hierarchy.
      • Alternative (more invasive): Assign all child Features/Stories to a shared planning iteration. This can conflict with team sprint boards, so use only if needed.
      To check/set:
      1. Open the Epic you want to burn down.
      2. Verify the Iteration Path aligns with your timebox (e.g., a Quarter or PI node).
      3. If your portfolio uses quarterly buckets, ensure the Epic is assigned to the correct quarter (e.g., Portfolio Mgmt\2026 Q2).

      Part C — Configure the Burndown (Analytics) widget

      1. Go to your Dashboard where you added Burndown (Analytics).
      2. Click the wrench (configure) icon on the widget.
      3. Set these key options (names can vary slightly by UI version): Scope / Team
        • Team: Portfolio Mgmt (OK if this rolls up across teams)
        Timebox
        • Iteration: Select the timebox iteration that contains the Epic (e.g., your Quarter/PI node).
        Backlog level
        • Choose Epic.

          This is critical—choosing Epic unlocks the descendant rollup behavior.

        Measure
        • Burndown by → Sum of a field → Story Points.
        Rollup
        • Turn ON:
        • Include descendant items (or Include child items in calculation)
        • Roll up values from child work items
        • If you see a control like “Progress is calculated by”, set it to Descendants (rollup).
        Completion logic
        • Completed when → State category = Completed
          (Adjust if your workflow uses custom Done states/categories.)
        (Optional) Filter to a specific Epic
        • If the widget version supports a filter:
        • Field: Parent (or Ancestor)
        • Operator: =
        • Value: your Epic ID = 1
          If you don’t see a filter, the Epic context will come from the Backlog level (Epic) + Iteration selection. In that case, make sure only the Epic(s) you want are in that iteration during the timebox.
      4. Save the widget configuration.

      Part D — Validate data shows as expected

      After saving, check:
      • You see a declining line for Story Points remaining over the timebox.
      • If the line is flat at zero:
        • Verify child Features/Stories have Story Points (non-empty).
        • Ensure the Epic is in the selected Iteration.
        • Ensure Epic backlog is enabled (Part A) and Backlog level = Epic in the widget.
        • Confirm the rollup/descendant options are ON.
        • Check state categories—if your Done states aren’t mapped to Completed, the burndown won’t decrement. You may need to choose specific states instead of category.
Azure DevOps

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Praveen Kumar Gudipudi 2,280 Reputation points Microsoft External Staff Moderator
    2026-03-17T09:02:45.07+00:00

    Hi @Rupert Schmidtberg ,

    You’re running into a real limitation of the Burndown widget in Azure DevOps, and unfortunately the guidance you received earlier mixes capabilities from different widgets and older implementations.

    Key clarifications

    The Burndown (Analytics) widget does not support query-based input

    It also does not perform hierarchical rollup (Epic → Feature → User Story)

    There is no hidden configuration or extension point in the widget to enable this

    So the suggestion to:

    “select a query in the widget”

    …is not applicable to the Analytics Burndown widget you’re using. That option existed in older/classic scenarios but isn’t available here.

    About extending the widget

    The built-in Burndown widget is not open-sourced, and its implementation is part of the Azure DevOps service. You won’t find its code publicly available to modify.

    However, if you want to build your own version:

    You can use the Azure DevOps Dashboard Widget SDK

    Pull data from the Analytics OData feed

    Implement your own hierarchical rollup logic (Epic → Feature → Story)

    This is the supported extensibility path, but it does require custom development.

    What your current options realistically are

    1. Iteration-based workaround (native, but limited)

    As mentioned earlier:

    Use Stories level

    Scope by iteration (portfolio timebox)

    This works only if:

    The Epic’s work is isolated within that iteration

    1. Power BI (most practical for true rollup)

    Using Power BI with the Analytics OData feed lets you:

    Traverse full hierarchy (Epic → Feature → Story)

    Aggregate Story Points correctly

    Build a true Epic burndown

    This is currently the most reliable way to achieve what you’re after.

    1. Custom dashboard widget

    If you’re open to building one:

    Use Analytics OData

    Recreate burndown logic with rollups

    Publish as a private extension

    Final note

    Your expectation is completely valid—true hierarchical burndown is a common need. At the moment, it’s simply a gap in Azure DevOps dashboards, not a configuration issue on your side.

    If this capability is critical out-of-the-box, tools like Jira (with marketplace apps) do currently offer more flexibility in this specific area.You’re running into a real limitation of the Burndown widget in Azure DevOps, and unfortunately the guidance you received earlier mixes capabilities from different widgets and older implementations.

    Key clarifications

    The Burndown (Analytics) widget does not support query-based input

    It also does not perform hierarchical rollup (Epic → Feature → User Story)

    There is no hidden configuration or extension point in the widget to enable this

    So the suggestion to:

    “select a query in the widget”

    …is not applicable to the Analytics Burndown widget you’re using. That option existed in older/classic scenarios but isn’t available here.

    About extending the widget

    The built-in Burndown widget is not open-sourced, and its implementation is part of the Azure DevOps service. You won’t find its code publicly available to modify.

    However, if you want to build your own version:

    You can use the Azure DevOps Dashboard Widget SDK

    Pull data from the Analytics OData feed

    Implement your own hierarchical rollup logic (Epic → Feature → Story)

    This is the supported extensibility path, but it does require custom development.

    What your current options realistically are

    1. Iteration-based workaround (native, but limited)

    As mentioned earlier:

    Use Stories level

    Scope by iteration (portfolio timebox)

    This works only if:

    The Epic’s work is isolated within that iteration

    1. Power BI (most practical for true rollup)

    Using Power BI with the Analytics OData feed lets you:

    Traverse full hierarchy (Epic → Feature → Story)

    Aggregate Story Points correctly

    Build a true Epic burndown

    This is currently the most reliable way to achieve what you’re after.

    1. Custom dashboard widget

    If you’re open to building one:

    Use Analytics OData

    Recreate burndown logic with rollups

    Publish as a private extension

    Final note

    Your expectation is completely valid—true hierarchical burndown is a common need. At the moment, it’s simply a gap in Azure DevOps dashboards, not a configuration issue on your side.

    If this capability is critical out-of-the-box, tools like Jira (with marketplace apps) do currently offer more flexibility in this specific area.

    0 comments
  2. Q&A Assist
    2026-03-02T18:02:41.9966667+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    The Burndown widget in Azure Boards does not expose a “Rollup” section in its configuration. Instead, it rolls up work based on:

    1. The backlog/work item type you choose
    2. The field you burn down on (for example, Story Points or Remaining Work)
    3. The hierarchy and estimates of the underlying work items

    To get an Epic-level burndown that reflects progress of child Features and User Stories, configure and use the widget as follows, using only the options that actually exist in the UI.

    1. Add the Burndown widget to a dashboard
      1. Go to https://dev.azure.com/{your-organization} and open the project.
      2. Select Dashboards → Edit.
      3. In the widget catalog, select Burndown (Analytics-based) and choose Add.
    2. Configure the widget to track Epic scope
      1. On the widget, select the gear (Configure) icon.
      2. In Teams, select the team that owns the Epic (for example, your portfolio team). You can add more teams if the Epic spans multiple teams.
      3. In Work items:
        • Choose the backlog or work item type that represents the scope you want to burn down. For an Epic burndown, this is typically the Epic backlog or the Epic work item type.
        • Ensure that the child Features and User Stories are linked correctly under that Epic and have the numeric field you plan to burn down on (for example, Story Points or Remaining Work).
      4. In Time period:
        • Set Start date to the beginning of the timebox for the Epic (for example, the start of a release/PI).
        • Set End date to the target completion date for the Epic.
      5. In Plot interval:
        • Choose how to plot the burndown (for example, by Iteration or by weekly/monthly intervals). If plotting by iteration, select a start date and set Plot burndown by to Iteration.
      6. In Advanced features:
        • Optionally enable Show total scope to visualize scope increase over time.
        • If the team uses a Resolved state (or equivalent) and wants those items treated as done, enable Show Resolved work items as Completed.
        • Under Burndown chart options, enable:
          • Show burndown to see remaining work over time.
          • Show completed work if a stacked bar view of completed work by type is useful.
          • Plot remaining work using work item type color if different colors for Epics/Features/Stories help interpret the chart.
    3. Ensure data supports an Epic burndown
      • Child Features and User Stories must:
        • Be correctly linked under the Epic.
        • Have values in the numeric field used for burndown (for example, Story Points, Effort, Remaining Work). Items without a value will show under Items not estimated when burning down on a field sum.
      • The Epic and/or its child items should be in the Area Path and Iteration Path that the team and chart are scoped to.
    4. Interpret the Epic burndown Once configured, the widget provides:
      • Original scope: Remaining work at the Start date; used as the baseline for completion percentage and Total Scope Increase.
      • Total scope: Combined completed + remaining work, showing scope change over time.
      • Burndown: Remaining work trend; past points are actuals, future points are projections.
      • Projected completion: Calculated from remaining work, historical burndown, and scope change; shown as a vertical line if before the End date, or as text indicating extra intervals/iterations needed if after.
      • Items not estimated (when burning down on a field sum): count of items without a value in the chosen field; select it to see the list and fill in missing estimates.
    5. Important constraints and cautions
      • The widget can track progress across multiple teams and projects only when the process is the same or similar for those projects.
      • If using a hosted XML process and Bugs are customized into a different category, they must still belong to the default Bug category (Microsoft.BugCategory) to be included when burning down on a backlog that includes bugs.
      • Do not delete or reconfigure Area Path or Iteration Path values used by the Epic and its children; doing so causes irreversible data loss for burndown, burnup, sprint burndown, velocity, and historical trend charts.

    In summary, an Epic burndown is achieved by configuring the Burndown widget to:

    • Use the Epic-level backlog or work item type as the scope,
    • Burn down on a numeric field that is populated on the child work items,
    • Use appropriate dates/iterations and advanced options (scope, completed work, colors), while relying on the existing hierarchy and estimates rather than an explicit “Rollup” toggle in the widget UI.

    References:

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.