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:
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.
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.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
As part of the Bitbucket product team I'm always interested in better understanding what kind of impact the use of our tools have on the way you work. In a recent study we conducted of software devel...
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!
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