nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Version burndown report - why doesn't it use velocity from previous versions?

Simon.Wilson

Hi,

We've been using both the version and the version burndown reports to help predict when we have all the features we need for a release.

Each time we start a new release, the version burndown won't give any prediction until three sprints have been completed. Why doesn't it use the velocity from prior sprints? There is no change to the team's composition etc. so the velocity should be relevant.

TIA for any pointers.

/Simon

Accepted answers

All comments

Bill Sheboy

Hi @Simon.Wilson

You may want to suggest using historical velocity for the release burn chart as an improvement to Jira.

According to the help info, using the velocity history for the specific version (release) is the intended behavior for how the report works: https://confluence.atlassian.com/jirasoftwarecloud/release-burndown-777002702.html

Best regards,

Bill

Simon.Wilson

Thanks for taking the time to reply Bill. It's been a while since I last used Jira cloud but I'm sure it didn't work like this before. Having to wait three sprints is a pain for us, guess we'll have to continue using the version report in the meantime.

Bill Sheboy

Thanks, @Simon.Wilson

If you need a more immediate, non-Jira solution... you could always export your version-specific work and make a product burn chart in Excel. I have been doing that for years when tools like Jira, Rally, V1, etc. cannot yet provide the work-support info for teams I help.

Simon.Wilson

Yeah, I'm just lazy

chris.atkinson

Voted for this as well... Having to wait 3 sprints is not a realistic option when the rest of the company is looking for forecasting data.

Gordon Bissell

Agreed. It makes the velocity data useless for the projects we do. In the end I wrote a script to query the database via the python jiratypes library, calculate velocity, and produce a web page with graphs using plotly. Not ideal, but it means we can obtain and maintain velocity data for a team across versions.

Point being; all the data to do this is in the Jira database, so there's no reason it couldn't be offered.

Todor Vlaev

Based on comments it’s not possible to use historical velocity data before the release start date.

But I wonder if there is a possible hack around this. Like having a fake overlapping release that captures all the current release content and in addition 3 sprints of historical data.

Again, this is a hack, so it’s ugly - you’d need the hack version alongside the real version in the field. Also means to select the right set of issues from the 3 historical sprints.