Burnup charts for two identical filters and work scope mapping have different work scopes

[gabriel_clarkson]

Hi, I was hoping to get some help with understanding why there is a difference in work scope across the burnup charts for these two boards.

Context: The 'Data Team Board' definition of done includes QA, but QA time isn't yet estimated. So we are creating a temporary second board which pulls the same work items, but includes QA statuses in DoD.

Both boards are in the same, company-managed project.

Both boards use the same, identical filter.

Both boards have identical mapping of statuses in 'To Do' column.

In backlog, both boards have the same total SP.

But in the burnup charts, there is a disparity of 30-50 SP between the two charts. 

I've tried tweaking JQL, and no changes pull through. I did just recently create one of these boards; is it something to do with the timing of the board creation being after the Sprint started?

Thanks

[Danut M _StonikByte_ · Accepted solution]

Hi @gabriel_clarkson

Try comparing / looking at the data from the tables under these charts to see the evolution of the Work Scope over time. This should help you identify the issues that are causing these differences.  

Danut.

[gabriel_clarkson]

@Danut M _StonikByte_ Thanks, upon checking this I am still confused, as in the board with the lower work scope, it is missing issues from the list.

For example, I have one issue which was added to the sprint 1 day before the sprint begun, and it is visible in one of the boards, but not the other.

The JQL filter for the boards is the exact same filter.. so I'm struggling to understand why this is happening

[Danut M _StonikByte_]

Hi @gabriel_clarkson,

Not sure why this happens. Maybe the issue was already in the done state (in QA status) when it was added to sprint and the board does not count it because you mapped QA status on its done column?

You could eventually open a ticket with Atlassian Support to get this clarified; it is hard to troubleshoot here not having access to your data. 

Also, instead of struggling with these Jira reports, you could consider using an app from the Atlassian Marketplace.

If you want to try an app, our Great Gadgets app offers all you need for tracking your agile projects efficiently. For example, it offers a Sprint Burndown Burnup Chart gadget that allows you to set certain states as done (according to your DoD) without having to duplicate or modify agile boards.

The app offers many other gadgets such as Release Burndown Burnup Chart or Team Velocity gadget so it can be a full replacement for the Jira's reports. Have a look on these article: https://community.atlassian.com/forums/App-Central-articles/8-gadgets-for-a-powerful-Scrum-dashboard-in-Jira/ba-p/1683063 

Danut 

[gabriel_clarkson]

Thanks Danut for your insights. We have some issues which are running across sprints (addressing this as part of our agile review), so your thought about QA status is an interesting one. I'll check out some of the related issues and see their status history.

I'll also check out the app posted. Cheers!

[gabriel_clarkson]

@Danut M _StonikByte_ Just wanted to follow-up and say thanks again; you are quite right that the reason for this is the issues being in QA status when the Sprint begun I think.

Appreciate your help!