Documentation for GreenHopper 6.2.x. Documentation for earlier versions of GreenHopper is [available too].

バージョンレポートの表示

Created by Rosie Jameson [Atlassian], last updated on May 29, 2013 2 minute read

The Version Report shows your team's progress towards completion of a version. The Version Report also shows you the predicted Release Date, based on your team's average rate of progress (velocity) since the start of the version, and the estimated amount of work remaining.

This page only applies to Scrum boards.

関連ページ

バージョンレポートを表示する手順は、次のとおりです：

上部ナビゲーションバーで Agile リンクの下矢印をクリックし、表示されるドロップダウンメニューから目的のボードを選択します。
Click Report, then select Version Report from the drop-down at top left.
バージョンドロップダウンから該当のバージョンを選択します。

スクリーンショット：バージョンレポート（クリックで拡大）

The horizontal axis starts on the version's Start Date; or if no Start Date is specified, the date on which an issue was first added to the version. The graph shows the state your version was in at any given point in time, in terms of your total and completed Story Points (or other Estimation Statistic of your choice), so that you can see how the scope may have changed, and how you are progressing towards completion of the estimated work.

グラフは次の予測を表示します：

the Predicted Release Date (blue line) – that is, the date at which you can expect all issues in your version to be complete, based on your average daily velocity and the amount of estimated work remaining.
the Predicted Release Date (Optimistic) (shaded area to the left of the blue line) – that is, the earliest date by which you might expect the version to be complete. (The "optimistic" date is calculated by adding 10% to the average daily velocity.)
the Predicted Release Date (Pessimistic) (shaded area to the right of the blue line) – that is, the latest date by which you might expect the version to be complete. (The "pessimistic" date is calculated by subtracting 10% from the average daily velocity.)

予測値を計算するには、バージョンの見積済み作業のうち 10 %が完了している必要があります。

注意

バージョンレポートはボード固有、すなわち、ボードの保存済みフィルターに一致する課題しか含みません。
The Version Report shows Released versions but not Archived versions. (For more about version status, please see the JIRA documentation on Managing Versions)

32 Comments

mpaluchowski
Apr 12, 2013
Are there any preconditions (ie. number of sprints or stories completed) for the release date prediction to appear? We're running JIRA 5.2 and GreenHopper 6.1.6, the trend line is there, but the report chart stops at today's date and doesn't show the predictions at all.
1. Rosie Jameson [Atlassian]
  Apr 14, 2013
  You will need to have completed 10% of the estimated work before the predictions can be calculated
  1. mpaluchowski
    Apr 15, 2013
    That's 10% of total Story Points I assume? (or any measure we've chosen) May I suggest a hint at that is placed on the Version Report? This totally wasn't clear for me.
mpaluchowski
Apr 16, 2013
Is there a feature planned to exclude Technical Tasks from the Version Report? Right now JIRA automatically adds them to the same version their parent has, and the Version Report shows them as a spike in the "Unestimated Issues" count. But we never estimate on task level, only on User Story level.
1. Rosie Jameson [Atlassian]
  Apr 17, 2013
  I don't believe such a feature is planned; you may like to log a request at http://jira.atlassian.com
  Alternatively, you may want to consider using sub-tasks for your Technical Tasks.
  1. mpaluchowski
    Apr 17, 2013
    We are using sub-tasks And if I understand correctly, these shouldn't show up in the Version Report, but they do.
    1. Rosie Jameson [Atlassian]
      Apr 19, 2013
      
      My apologies. I see you have found GHS-8152 - Getting issue details... STATUS regarding this – thank you for your input.
Peter Callies
Apr 22, 2013
What determines the start date used on the chart? How does one edit this once the version has already been created?
1. Rosie Jameson [Atlassian]
  Apr 24, 2013
  In GreenHopper 6.2, you can now specify the version Start Date – please see Editing or Renaming a Version
Tim Baker
Apr 22, 2013
Is there a dashboard gadget that we can use to track this on our dashboards? The classic board has one, which I've continued using, since nothing better has been available, but I like this one more (plus, the classic board will go away, some day), and would love to see it each time I log into JIRA.
Thanks for the nice new report. I like it!
1. Rosie Jameson [Atlassian]
  Apr 24, 2013
  We don't yet have such a gadget, sorry. You may like to comment on GHS-5345 - Getting issue details... STATUS ?
  1. Tim Baker
    Apr 24, 2013
    Thank you, Rosie. I'm now voting for and watching that JIRA ticket. If anyone else is interested in this functionality, I would suggest that you do the same.
Peter Callies
Apr 26, 2013
How is top of the vertical axis calculated?
1. mpaluchowski
  Apr 26, 2013
  It's the sum of all Story Points (or whatever estimate you use) from issues assigned to a given version.
  1. Peter Callies
    Apr 26, 2013
    I don't think so. That is represented by the shaded gray area, right?
    1. mpaluchowski
      Apr 26, 2013
      
      Yes, and the left-hand vertical axis shows the number of points that this "grey area" covers, as well as points completed (shown by the blue area).
      The right-hand side axis shows the percentage of issues in a version which are not estimated (red line on chart).
      1. Peter Callies
        Apr 26, 2013
        
        I've got an example, but I can't attach an image here and it's tough to explain with words, but I'll try.
        The last couple weeks of our quarterly releases (i.e. versions) are used for regression testing, automation enhancements, planning, R&D, etc. These don't have story points associated with them so our Completed Story Points flatlines at the end of the release and always comes up short of the top of the vertical axis. This is fine – it's an intentional choice we've made.
        At no time during the release does the percent of unestimated stories or total story points approach the maximum of the vertical axis so it can't be determined on that.
        My hypothesis is that the maximum is calculated using completed story points and velocity, but I'd like to know exactly how that works. I'd also like to know at what point during the release that is locked in.
        
        Rosie Jameson [Atlassian]
        Apr 29, 2013
        
        I'm not sure if I'm understanding the question correctly, but the Optimistic Release Date is calculated on-the-fly whenever the Version Report is generated. If I've misunderstood the question, can you please contact http://support.atlassian.com ? Thank you
Kershnee Govinder
May 19, 2013
Can the calculations be configured to include two values? Story points and a custom field (high-level estimate)? Reason I ask, the story points field is only populated once grooming has been completed with the team. We would like to make use of the custom field (high-level estimate) which will contain a value. Thank you.
Troy Johnson
May 24, 2013
It says that the "Predicted Release Date" is calculated "based on your current daily velocity". How do you calculate a "current daily velocity". There may be days when no stories are completed and thus the daily velocity is "0". You must be using some other calculation method of an average daily velocity based on some criteria. Can you explain this a little more please. Thanks.
1. Rosie Jameson [Atlassian]
  May 26, 2013
  We actually use the average velocity – I have changed "average" to "current" in the text. Hope this helps. Many thanks for the question.
  1. Troy Johnson
    May 27, 2013
    Rosie, thanks for the response. This does make more sense. There is still a question in my mind though and that is how is the "average daily velocity" calculated? Is this calculated over the the time period of the sprint itself or does it actually span several sprints? Are you looking at the information that is displayed in the Velocity chart to calculate that value? Thanks in advance for your help.
    1. Rosie Jameson [Atlassian]
      May 28, 2013
      
      It's the average velocity since the start of the version – I've now put that in the doc too. Thanks!
Laszlo Kremer
Jul 22, 2013
Will the version report get a more refined UI? Release managers like the pervious UI way better, because they could track the tickets more easily.
Maybe having dynamic fixversion qucikfilters on a kanban board could do the job.
Mike Sorensen
Aug 06, 2013
This report seems to get confused when the items have multiple versions. We are maintaining two types of versions for a product, Let's call them 2-number and 3-number versions. The 2-number versions are targeted for customer release. The 3-number versions are for significant iteration releases. As such, many issues are in a open 2-number version (for the planned customer release) and a second closed 3-number version (for the iteration). We want to see this report for the 2-number version but many of the issues seem to be hidden (maybe because they were in a closed 3-number version?).
We do this two types of version numbers to generate version reports we use to submit to QA.
Bas Burgers
Aug 06, 2013
The time axis in my Version Report starts from the start date and ends on today.
Why does the time axis not end at the release date?
The graph shows a prediction line (only after a few days), but it is useless because the prediction and the graph end at today.
So I don't now if the team will finish before the release deadline.
What can I do to fix this ?
1. Bas Burgers
  Aug 13, 2013
  After a few days the end date of the time axis was extended such that I could see when the current version would be done (according to greenhoppers prediction).
  After a few days I had to add a few user stories to the version.
  Unfortunately this broke the version graph because the grap stops again at the current day, which makes it useles for me.
  Is this a bug, or am I doing something wrong?
  1. Bas Burgers
    Aug 13, 2013
    Created an issue:
    https://support.atlassian.com/ja/browse/JST-72676
  2. Dobroslawa Wierzbicka
    Aug 14, 2013
    Hi Bas,
    See the note in the article:
    Note that 10% of the estimated work for the version will need to be complete before the predictions can be calculated.
    
    I take it that you've finished 10% of the planned work first, and then added new Stories - as the total amount of work increased, and so work done until today became less than 10%. Once you get to that level again, the predicted end dates will be displayed.
    1. Bas Burgers
      Aug 15, 2013
      
      Because of the added work, indeed the percentage of done work became less then 10%.
      Could at least a note be added to the graph telling how much work needs to be done to get a prediction ?
      As a user I don't understand why 10% completion is needed for a prediction. I understand a prediction based on a lower precentage or even 1 task is less acurate, but it is at least a prediction that I don't need to calculate manually. In case a version takes 7 months/28 weeks, it would take almost 3 weeks to get a prediction.
      The project leader of the customer wants a prediction earlier, forcing me to do it manually .
      1. Dobroslawa Wierzbicka
        Aug 15, 2013
        
        Here's a feature request to display predictions earlier: GHS-9679 - Getting issue details... STATUS
        Please keep in mind, though, that should these predictions be included, they'll be highly inaccurate; that was the reason the 10% threshold was implemented in the first place.
Pete Jaffe
Aug 07, 2013
I'm thrilled to have the Version Report in the Scrum (Rapid) Board now, and I'm seeing some great suggestions tracked in JIRA. I figured I would call out a few here that resonated with me:
- While looking at the current contents of a particular version is likely one of the most common desired views, I would love to be able to look out two or more versions, which I imagine would need to aggregate the completed and remaining items from the set of versions, and build a combined projection. I found this was submitted by someone under GHS-9237: Multiple versions in version report
- I would also like to run "what if" scenarios where I might want to exclude all remaining open items in a version that are below a particular priority. So, some kind of quick/custom filter would be helpful. This was mentioned in GHS-9237, but I created another issue to track this explicitly: GHS-9645: Allow various filters (and multiple versions) in the Version Report
- I also found GHS-9604: As an agile user, I would like the option to change the predicted completion date based upon recent velocity to be a very thoughtfully presented suggestion that could account for "correcting" a version report when real life situations start to make it less accurate. Although, as the author of that issue noted, this is likely a more complicated request.
Thanks for the Version Report, which I think is an absolutely critical view. I look forward to seeing it continue to evolve.
Pete