Stacked burn-up chart for a release

Get Help
1

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.

2

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’.

3

(Sorry for the delay replying - right after I posted this, I got pulled away from this problem.)

I hadn’t seen that guide before - it helps! I suspect you are right.

But I’m not sure how to address it - I somehow need to limit that historical data to “just one event per day” (or per week), right? I don’t know how to do that.

I can imagine trying to filter just on state-change events, too. I’m not sure how to do that, but even if I could, it seems like it wouldn’t work if there were two state changes on the same day.

And thinking further, if the Sum(Estimate) is based just on events from a particular day or week, how could that be correct, if some entities weren’t updated in that particular day or week? Does the TIMELINE function handle that for me, somehow?

Maybe a chart like this is impossible, in Fibery? Or if it’s not impossible, I’m not sure how to approach making it.

4

Just a status update: I tried a table, which confirmed that the data looks as the guide described it. I also found that I can filter the chart (or the table) by “Changed Fields”, but as soon as I do that in the chart it seems to lose the history - I don’t get the cumulative sum over time; I just get the sum of the events on any particular day. So I think I’ve confirmed my worries from my prior posts - so now I’m stuck. Is there a path forward?

5

OK, one more. Just as I was closing everything down, I got a perfect chart, exactly the way I want it! But I think it’s a bug. And even if it works, it isn’t useful.

What I originally tried:

  • Filter the source data by “Releases is not empty”.
  • Configure the chart with TIMELINE (as described above) on the X axis, and SUM(Estimate) for the Y axis.
  • “Finish” the report.
  • Use the user-facing report filter to choose a specific release.

That didn’t give correct data.

But just now I tried this:

  • Filter the source data by “Releases contains ”.
  • Configure the chart the same way.
  • Just look at the data, still in the “Configure” view.

The data is correct! At least it looks right, from my understanding of what happened in the real world. And crucially, the total of the estimates, for today’s date in the chart, matches the actual total of the estimates, as of today.

But then, when I “Finish” configuring the report, and go back to the regular user-facing view - the data is wrong! And refreshing it doesn’t fix it!

So that seems like it must be a bug - the exact same configuration gives different results in the “Configure” view vs. the “User” view.

So then I went back and re-tested my original scenario, and I see the same problem - the results are different in the “Configure” view vs. the “User” view. But in that case, they’re both wrong.

So the only case where I can get the correct chart is in “Configure” view - which is useless for sharing the chart with my team.

(And one way or another these charts don’t seem trustworthy.)

6

Can you share some screenshots, or even better, a video - it doesn’t sound quite right, but there are circumstances where the data shown during configuration can be different than the data shown when in ‘view mode’, so we need to figure if this really is a bug, or just unintuitive behaviour.
Alternatively, if you prefer, you’re welcome to chat to us in the app and/or invite one of us into your workspace for debugging purposes.

7

OK. I’m not comfortable posting a video of our data here, so I’ll chat you later today. Does it need to be from the desktop app, or is it OK to do it from the browser? I’m happy for you to be able to poke around.

8

If you want to securely share video/screenshots then you can reach out to us via the in app chat.
Alternatively, you can invite me (chris@fibery.io) into your ws

9

I invited you to our workspace as an admin.

It’s the Development space, then Reports folder, then “Release burn-up” report. The specific release I’ve been testing with is 8.2.72. Its current “total points” (for comparison to the chart) can be seen on the Releases view in the Planning folder.

Thank you!

10

…and of course, I think I found part of the problem. I just realized that I still had a user-selectable filter set. When I removed it, the chart looks correct.

I still think there might be a bug - I had the user-selectable filter set to the same value (Release 8.2.72) as the admin-side filter was set to, so it seems like the results should have been the same. But at least this gives me a way to make a user-facing report that seems to be accurate.

I’m going to go back and re-test the cases and try to summarize them here again.

11

For each case, I’ll report the value of SUM(Estimate) as shown on the chart for today’s date, to compare to the “real” value as shown in just a simple view showing the formula field that calculates the same current sum - which is 58.25.

  • With the report “source” filter set to “Releases is not empty”:
    • With the “Configure” filter set to 8.2.72: 39.75
    • With the user-side filter set to 8.2.72: 39.75
  • With the report “source” filter set to 8.2.72:
    • With no additional filters set: 58.25
    • With the “Configure” filter set to 8.2.72: 39.75
    • With the user-side filter set to 8.2.75: 39.75

So I have a way to see the right data - set the “Source” filter to a specific release. (And don’t then set any further filters.) But there’s still an inconsistency here that doesn’t make sense, in terms of different filter fields giving different results.

I’m also sure I saw different results in prior tests than I’m seeing now… but maybe that was all just user error, and I had double-filters set, or missing filters, or something.

12

Thanks for giving me access - it really helped with understanding the structure and data that you are working with.
I have created a smart folder of Releases (with a filter for only those which have linked Work Items (via the Work Items (Found In) relation, but perhaps this is the wrong field?)

Each Release has its own (mirrored) historical Report, which is context filtered to use the linked Work Items as the source data.
Within the report there is

  • a table visualisation to show the raw event data for the Work Items (showing the events where the State or the Estimate changed)
  • a burn up chart showing the value of Estimate over time, colour coded by the State

I hope this is close to what you were after. I don’t see any issues when switching from configuration to view, and the data looks right as far as I can tell.
Please let me know if you spot any anomalies.

13

Thank you for your work on this!

But: the Work Items (Found In) field is the wrong one. The one we need is Work Items (Release). Back when I first tried this, and assumed it was working, I had also tried setting up a smart folder. But I got this error:

image
image395×121 7.04 KB

(This is from just now, when I tried to convert what you did to use the Release field.)

I tried to put things back the way you had them. Do you have any more ideas about this? Maybe the problem (with the data filtering) is that it’s a many-to-many field?

14

Yes, unfortunately, we don’t support m:m relations as a context filter for historical reports.
The next best thing is to create a single report, and then use a live view filter which users can change.
I have created one for you. Let me know what you think

15

I think you’ve done the first thing I tried, and it gives the wrong results. For example, if I set the user-side filter to 8.2.72, the total in the chart for today is 39.75, but it should be 58.25. This is exactly the problem I was describing above.

16

Can you share a screenshot. I see the total as 58.25 when I set the filter to 8.2.72

image
image1602×776 67.9 KB

p.s. if you want to continue in a customer support chat, feel free

17

Fascinating! It’s nice to see some evidence that I’m not crazy about the results being different from time to time.

I’m in meetings all morning; I couldn’t be responsive on support chat. I’ll try that this afternoon, if we still need to.

image
image2221×1298 159 KB

18

Oh! I just realized the issue - “Contains” vs. “Contains only”. My mental model was wrong.

I was assuming “Contains only” was like “Contains” (in entity filters) and “Contains” was like “Contains any of”.

But really “Contains only” means “the only assigned Release to that Work Item is this one specific release specified in this filter, and there are no additional Releases assigned to that Work Item”. I guess I see how that might be useful in some cases, but I didn’t even realize that was a thing you could do.

I see that you chose “Contains” and I chose “Contains only”. When I switch to “Contains”, I see the same - and correct - results!

So it works!

Thank you, and sorry for the confusion.

19

Hoorah!
I am so glad that we reached a successful conclusion. Reports are pretty complex, so it can be a real challenge to get things right.
Ping us again if you ever encounter anything odd.