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

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

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

[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 :)

[Shane Gannon]

Is there any way around this - what if the release is 4 sprints long?

[Bill Sheboy]

Hi @Shane Gannon 

Other than exporting to another tool, there does not appear to be a work-around within Jira. 

I found this suggestion made in 2014 for the same request @Simon.Wilson is making:

https://jira.atlassian.com/browse/JSWCLOUD-11455

Best regards,

Bill

[Shane Gannon]

Thanks Bill - I have voted for the issue. 

Can anyone recommend an alternative (Free) tool. 

[Gordon Bissell]

Atlassian's Release-Ready Team infographic (https://www.atlassian.com/blog/wp-content/uploads/Atlassian_The-Release-Ready-Team-infographic.jpg?_ga=2.111372551.2065591883.1560938313-683160149.1513179492) indicates that a 10 day average sprint, and 15 days between releases is a "good" rule of thumb.

But, if you need three completed sprints (30 days) on a release before you get forecasts, but you're releasing every 15 days, you'll never get forecasts on a release.

Or have I misunderstood?