How are you measuring scope growth against a Jira baseline?

[Sevastian]

Curious how others handle this:

When you set a release scope in Jira, how do you track:

• Issues added after the baseline?

• Estimate growth?

• Impact on delivery date?

Spreadsheets? Manual diffing?

I’ve been experimenting with a small tool that snapshots a JQL baseline and runs daily diffs to calculate scope growth % and projected schedule impact.

If anyone is interested in trying it out and sharing feedback, I’d be happy to give access. Mainly looking to learn how real teams approach this.

[Alexey Pavlenko _App Developer_]

Hi @Sevastian ,

If you use sprints, you can use the app I developed - Multi-team Scrum Metrics & Retrospectives.

1. Select period: sprints, months, quarters, half-years or years.
2. Select teams.
3. Check "Initial Scope" vs "Added Scope" on the Charts.

3 boards/teams in the same view, period = Sprints, 1 period selected for analysis:

3 boards/teams in the same view, period = months, all periods are clicked for average metrics and trends:

Additionally, you will be able to conduct quantifiable retrospectives on top of it.

Best regards,
Alexey

[Danut M _StonikByte_]

Hi @Sevastian,

Welcome to Atlassian Community!

You mentioned that you tried using Fix Version and gadgets, but apparently this approach did not work for you.

I would still recommend this method instead of handling the data manually in Excel. However, for it to work properly, you need to use the right gadget(s).

Have you tried the Release Burndown Burnup Chart gadget offered by our Great Gadgets app?  

This gadget is capable of tracking the scope and progress of your release, and it can also predict the ETA based on scope changes and the team’s velocity. All you have to do is to configure it with a filter that returns the issues from your release.

If you need any help, feel free to contact us at support@stonikbyte.com. We can also arrange a demo if needed.

Danut.

[Carlos Garcia Navarro]

Hi @Sevastian ,

Welcome to the community!

I’d recommend using Versions in Jira to establish your baseline. Once the scope is committed, use a label or component to mark any work items that get added afterward.

From there, you can:

- Export all issues tied to that version (your original baseline).

- Export the subset of issues in that version that have the added label/component.

If you export both to CSV, you can easily calculate scope growth and compare totals (issue count, story points, estimates, etc.) in a spreadsheet.

[Sevastian]

Hi Carlos, thanks for the warm welcome, I really appreciate it.

That’s a solid approach.
before building this, I was using versions and dashboards I created filters for the baseline scope, added issues, and estimate changes, then used gadgets to visualize issue count and story points to track growth.

What I found cumbersome was the manual overhead: consistently tagging new items, checking dashboards regularly, exporting data, and reconstructing what changed when stakeholders asked. It worked, but only if I stayed on top of it daily.

What feels easier with my current approach is defining a baseline once via JQL and letting automated daily diffs handle the tracking. Instead of monitoring dashboards, I’m alerted when thresholds are exceeded, with a clear breakdown of what changed and by how much.

Still validating whether that automation meaningfully reduces friction.
Really appreciate you sharing your method.