Getting the statistics burndown chart to properly burn down

Hi guys,

At work, we're running JIRA 4.4.5 and Greenhopper 5.8.7 (I'm warning you ;)). Here's the thing I'm currently running into:

To keep our history, I've imported all old issues and given them versions that happily match with our sprint numbers. This is ok, since we don't develop software by version.

Each version/sprint has a start date, end date and a release date, which I've set using the planning board. Sprint 8, for example, ran from 24 feb until 15 mar (2012). I changed the version on the planning board to reflect this. Once I release this version (JIRA mentions it's overdue on the Versions screen) it gets moved nicely to the "released board" where I can see the versions that already have been released.

For each sprint/version that I set up (the issues are connected to these versions already by means of importing them, but the versions themselves have no metadata until I set it up) you can see the released "versions" move from planning to released as I change them.

Even though all of the date fields in the issues connected to these versions (for example, version "sprint 8") coincide with the date constraints of the sprint (I fixed it up during import) none of the graphs on the released board reflect this.

This is how it's set up for sprint 8:

  • All issues have a fixVersion and an affectsVersion set for Sprint 8.
  • The issue dates fall within the versions release and start date (created, updated, due).
  • The boards are properly configured (statuses for Todo and Done) and the issues have the proper status. So for these past sprints, the issues fall into the rightmost column on the Task board, for example.
  • The issues have proper statistics (story points).
  • The issues are closed.
  • All mandatory fields have been filled in.

Yet, when I look at my released board, the statistics burndown chart (set on story points) has a horizontal "remaining values" line for story points. Even though all issues were closed on two days before the release date of the version, the graph stays horizontal. The required daily burndown rate jumps to 30 for the last date.

What am I missing? Shouldn't the graphs on the released board reflect the work that was done during the times set up for that version? If I work on version 2.0 of program X, shouldn't these graphs, after the release of said version, reflect how we got to version 2.0?

Here are some screenshots to reflect the situation (sprint 12). Please note that we use a different issue type, which may be the cause of all this trouble.

[1], [2], [3]

1 answer

1 accepted

I have found the solution. My imported issues (used CSV) do not have any history and it looks like (I haven't been able to confirm) the graphs I have shown above use the issue history to determine when changes to issues have been made (makes sense of course, in hind sight).

Ergo: without a history, nothing has "changed" in the issue (from state A to state B) ergo, they are never "solved", as far as the graph is concerned. Or something.

Thing is: once I hacked in a manual history entry (using MySQL and some tinkering) for a date half-way my version/sprint, the graph dutifully dropped down one issue at that date.

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,104 views 13 19
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot