Stacked burn-up chart for a release

Hi, I’m trying to make a release-based burn-up chart in Fibery, and I can’t seem to get it to work.

For reference, I’m trying to build something I’ve been able to build in Jira (via plugins) and that Linear had built-in: a time-based stacked area chart showing the scope of a release, over time, broken down by work item state.

The relevant databases are “Work Items” and “Releases”, with a many-to-many relationship between them.

I tried doing what I thought should “just work”: a historical-data chart using the Work Item database, with time as the X-axis (WEEK(TIMELINE([Modification Date], [Modification Valid To], TRUE)) (per what the AI suggested) and SUM([Estimate]) as the Y-axis. Then set the chart type to stacked-area, and the “color” to the State field.

The I use the Filter to select a specific release.

And that looks about right! But the data is wrong - the total of the estimates is much too high, and it isn’t representing the states and totals accurately, on any given date.

The AI suggested that the problem was that I was using user-selectable filters, and not the data source filter. I tried that, and the chart was better, but still not correct. (And I don’t like this solution. I don’t want to have to reconfigure the chart for each release, and sometimes we have multiple releases running concurrently. So an easy way to switch releases is important.)

The AI suggested that the problem was that a single Work Item could have many Releases, but its explanation sounds totally wrong, and doesn’t make sense to my understanding of how this should work. And we can’t really change that.

So now I’m turning here - is this possible? Am I doing something wrong? This seems like it should work, but it doesn’t, and I’m not sure why.

First of all, I wouldn’t trust AI to give good advice when it comes to complex reports (and historical data reports are complex!)

Second of all, if you haven’t already, please read this guide:

Overall, I recommend to people that they consider first creating a table visualisation in order to satisfy themselves that they know what the raw data they are working with looks like. Trying to guess why the heights of bar charts, or the width of the stacked areas is not what you expect can be tricky.

In your specific case, with respect to this:

I suspect it is because entities are being counted multiple times.
Imagine that you have a single entity, which has its Assignees changed several times in one day (but with the State value remaining unchanged as ‘In Progress’).
There will be a data point for each event, so if you are counting based on State = ‘In Progress’, you will get a total which equals the number of events, despite the fact that there was only ever 1 entity which was ‘In Progress’.