Getting the statistics burndown chart to properly burn down

jc5x April 15, 2013

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

0 votes
Answer accepted
jc5x April 15, 2013

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 Sign up to answer