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

GreenHopper Labs enables our customers to test some exciting new functionality within GreenHopper, giving you a sneak preview of new features coming in future releases of GreenHopper.

Please note that Labs features represent work-in-progress. They may be incomplete, or may change before being incorporated into the product (some Labs features may never be incorporated into the product). We try to keep Labs features stable, but please note that we cannot guarantee that data used while evaluating a Labs feature will be completely intact.

Labs 機能を有効にする

「Labs」をオンにするには:

  1. Log in as a user with the 'JIRA Administrators' global permission.
  2. Select JIRA Administration from the top bar, then select Add-ons > GreenHopper.
    OR, if you are using JIRA 6.0 or later, click the 'cog' icon in the top bar, select Add-ons, then scroll down the page to the GreenHopper section.
  3. Under GreenHopper Labs, select the features that are of interest to you:

 

On this page:

並行スプリント

複数のアクティブな並行スプリントを有効にするには、並行スプリントをオンにします。たとえば、2 つのチームが同じバックログから作業している場合、各チームは自分たちのスプリントで作業できるようになりました。

このシンプルなアプローチでは以下の警告に注意してください:

  • ベロシティ チャートにはチームあたりのベロシティは表示されません。
  • 現在の実装は、各チームが同一の見積もりをすることを想定していますが、このような状況が実務で発生する可能性はほとんどありません。

この機能は現在開発中のため、現在のものから変更される可能性があります。

 

Analytics

Turn on Analytics to share your usage of GreenHopper with the GreenHopper development team. This provides us with insight into what features are being used, where customers are encountering difficulties, and where we should be focusing our time and energy.

 

 

 

 

 

 

 

110 Comments

  1. Arnt Witteveen

    Feb 01, 2012

    Is there any documentation on what to expect? If not, is this the right place to ask questions?

    I've created a sub task and a technical task for a few stories. They don't appear anywhere on the plan or work views in the scrum board (they do appear in the kanban rapid board). Is that a bug, something I did wrong, normal behviour, ...?

    1. Anonymous

      Apr 17, 2012

      It would be good to know... any answer?

      1. Shaun Clowes

        Apr 17, 2012

        Until recently (in GHS-4662) the reason that sub tasks did not show up on the work view was because they did not have the same Sprint as their parent. If you are using GreenHopper 5.9.5 this should no longer be an issue and sub tasks should appear on work mode. Some customers have said that when they add a story that had sub-tasks before they installed 5.9.5 to a Sprint they do not see those sub tasks in Work mode, if this occurs in your case please try editing anything about the sub task which should force its Sprint to resync (let us know if that happens to you because we're trying to establish if this is a persistent problem or an isolated issue).

        In an imminent release the sub tasks will be shown on the Plan mode as well. 

         

        1. Claude Boselli

          Jul 13, 2012

          Hello Shaun,

          Is there any update on the feature "sub tasks showin on the Plan mode" ?

          We've started using the rapid board for our agile env but it is challenging without the ability to dispatch sub-tasks of a story across multiple sprints.

          We used to have this in the "classic" boards.

          Also, do you plan to deprecated the classic boards at some point?

           

          1. Shaun Clowes

            Jul 15, 2012

            Hi Claude, 

            Yes, sub-tasks are now shown in a separate tab of the detail view for their parent story. 

            We do not plan to introduce functionality to have sub-tasks in a sprint without their parent story. If you need to dispatch the sub-tasks across multiple sprints just go ahead and include the story in each sprint, at the end of the sprint when there are still subtasks to be completed the story will go back to the backlog (so it can be included in the next sprint). 

            At some point we'd like to introduce 'split story' functionality so that a story could be split in to two, with the existing story keeping completed subtasks but the new story taking the incomplete subtasks. That's not in the short term plans though. 

            We're not planning on deprecating the classic boards any time soon though we are not actively enhancing them. 

            Thanks,
            Shaun 

            1. Anonymous

              Jul 26, 2012

              Hi Shaun,

              The sub-tasks are now shown in the detailed view of the parent story which is great.
              But, I was expected that a parent story will have as Estimate the sum of its sub-tasks estimates (I'm using GreenHopper with the Estimation Statistic = Original Time Estimate) but this does not happen.
              Now, if I set estimates in hours for the sub-tasks only and not on the parent story, the parent story will have no estimate in the Backlog... This causes inconvenience when making the sprint planning.

              And yes, I have Time Aggregation checked in GreenHopper configuration. 

              Is there a plan for having this functionality implemented?


              Thank you,
              Danut

              1. user-3fa47

                Aug 16, 2012

                Just ran into this issue as well.  The time estimates in subtasks aren't aggregating up to the parent story.  

                Of course, when this IS fixed, I'm concerned that we'll run into the "story across sprints" problem that was discussed higher in the thread, because EVERY subtask will presumably aggregate up, meaning sprint planning using aggregated hours will essentially be worthless without the ability to split stories.  I could have a story for "Feature X" which requires multiple sprints worth of subtasks, but all of the time from those multiple weeks' worth of subtasks will simply aggregate up to Feature X.

              2. Anonymous

                Aug 24, 2012

                Second this issue.

  2. Oleg Semykin

    Feb 11, 2012

    Hi!

    We use GH about a year and would like to thank GH team for a rally convenient tool for Scrum projects management.

    We almost satiscfied by GH functionality except maybe one feature I've described on Setting Up a Version Hierarchy

    So now we try to use Scrum Rapid Board instead of classic ones.

    There are some quesions by the moment:

    • Is there a way to see burndown chart, track velocity for RB sprint?
    • Will it be possible to edit issues easily like in Task and Planning borads? Simply klicking on desired field and update it.

    1. Shaun Clowes

      Feb 15, 2012

      Hi Oleg, 

      At the moment there is no burndown chart but we are working on it right now. 

      To edit issues we will emphasise the Detail View which appears when you click the issue key on the card, this view shows the fields for the story and they can then be inline edited. 

      Thanks,

      Shaun

  3. Adrian Fittolani

    Feb 15, 2012

    Burn Up would be great too (story point value delivered each day). Also, can I edit the "list view"? like I can on the task board? I mean, can I het more detail on each list item in the planning view (component, estimation, whatever)

  4. Arnt Witteveen

    Feb 16, 2012

    Accidentally logged some feedback in JIRA support: JSP-116923

    Shouldn't the link at the bottom of the agile parts link to the greenhopper JIRA iso the JIRA jira?

  5. Damon Gaylor

    Feb 21, 2012

    I may be missing something, I love the current Task board, but do like the new Plan view on the Rapid Board.  We primarily do Scrum and I don't see where I can see subtasks for stories in the Rapid Board/Scrum View.  Is there something I'm missing?  I'm getting ready to start a new project and would like to try and use the new rapid boards since that is the direction you are going.  Also, I have to have a burndown chart and I'm glad to see that is is coming soon.

    1. Anonymous

      Feb 28, 2012

      The plan view for the scrum board is great, no doubt about it. I am also wondering why I cannot see the sub tasks in the work view. It is kind of those we want to track progress on until the whole story is done.

      1. Anonymous

        Feb 29, 2012

        To reply to myself:

           Ok, så sub tasks in the sprint overview may/may not be useful at all. I look at this way: The scrum overview has the purpose of telling how many stories are in progress and how they are finished. All the sub tasks on a story is more a Kanban thing which incidentally shows an identical view except it also shows sub tasks.

          That said I still think it should be user configurable weather to use the sprint board with or without sub tasks to accomodate for teams that only want one view to show it all.

         

        1. Arnt Witteveen

          Feb 29, 2012

          Tasks for stories are an absolute necessity in scrum. Do you mean that you see tasks but not subtasks? If it's just about tasks, I've seen this acknowledged as an omission they are working on.

          1. Anonymous

            Feb 29, 2012

            We desparately need to see sub-tasks on our Rapid Board. Without it we simply can't use this tool for SCRUM. Is there any way I can turn this on? (I'm about to give up on RB here...)

            1. Shaun Clowes

              Feb 29, 2012

              Sub tasks currently don't show up because they do not have the same Sprint field as their parent. We are working on this as we speak so you should find greatly improved sub task treatment in the next couple of releases. 

              We are working hard to improve Scrum for RB and have released it to labs early so we can gather your feedback, thanks for sharing your thoughts with us. 

              1. Shaun Clowes

                Mar 19, 2012

                Please note that since GreenHopper 5.9 all au tasks automatically inherit the Sprint of their parent and appear on the Rapid Board work mode. Stay tuned for further improvements in the visualization of sun tasks with their parents on work mode. 

                Thanks, Shaun

                1. Pete Jaffe

                  Mar 19, 2012

                  Just to clarify this, I am currently evaluating an OnDemand deployment of JIRA & GreenHopper, and the System Info tab indicates it contains "GreenHopper - 5.9-xondemand-2" yet I don't see subtasks showing up in the Scrum Rapid Board. Shaun, is there any chance you were referring specifically to 5.9.1, or am I just missing something with regard to how to see the subtasks in the Rapid Board under version 5.9?

                  I did see the Blog post indicating that GreenHopper 5.9.1 is out but that it will be a few weeks before that reaches the OnDemand deployment (per http://blogs.atlassian.com/2012/03/new-greenhopper-5-9-1-with-more-rapid-board-for-scrum-features/).

                  In researching this a bit more myself, I exposed the "Sprint " custom field on my "Default Screen", and I can see the Rapid Board sprint value getting assigned to my stories, but the subtasks continue to not have a value for that custom field (regardless of whether I create the task before or after associating the story to the sprint).  I don't know whether you guys designed it so the subtasks explicitly get their "sprint" value assigned and have it track with updates to the parent story (as it seems was done on the Planning and Task boards), or whether it is implicitly inferred from the parent and hence would never actually exist on the subtask directly. (I'm personally hoping you took the latter approach, but I guess it shouldn't matter from an end user perspective).

                  1. Shaun Clowes

                    Mar 19, 2012

                    Hi Peter, 

                    Yes, in 5.9.1 all sub tasks will automatically inherit the Sprint field of their parent. I'm not sure why you would prefer the later approach, the field can't be edited on the sub tasks. You're right that it will be a couple of weeks before it rolls out to OnDemand. 

                    Thanks, Shaun 

                    1. Pete Jaffe

                      Mar 20, 2012

                      Don't read anything into my comment about "hoping you took the latter approach."  I was just trying to convey that I believed it might be more elegant to not denormalize the sprint identifier onto the individual subtasks based on the assumption those subtasks could never be associated with a sprint other than the sprint that their parent story is associated with (and hence they could just infer their sprint values).  However, as I think about it, I assume there would be a desire to map arbitrary JIRA issues into sprints outside of the story/subtask construct, and in that case I would imagine subtasks of a single parent could span multiple sprints... I still need to wrap my head around how to effectively use GreenHopper to manage JIRA "bug" issue types under the Planning/Task board, and now the evolving Rapid Board given that the tight integration with bug tracking was one of my primary motivators to drop my previous Scrum tool in favor of GreenHopper, given that I was already using JIRA for defect tracking. 

                    2. Anonymous

                      Aug 14, 2012

                      Hi Shaun,

                      We're migrating from hosted JIRA to on demand. Not being able to manage subtasks independently of parent tasks will most likely be the highest pain-point to our migration.

                      What do you recommend here? Manage the decomposition of a story as separate cards, then go back and link them? Is there a quick-feature to add a related card?

                       

                      1. Shaun Clowes

                        Aug 14, 2012

                        Sure, you could use a separate issue with a link to the related issue, that's something that many teams at Atlassian do. You could also allow the story to remain unfinished (with some of its subtasks complete) in one sprint, it will then go back to the backlog where it can be included in the next sprint where the subtasks are completed and the story is actually completed. 

                        There's no specific feature to add a related card, it's reasonably easy because you just hit 'c' to create a new issue, then click the link to the new issue then hit '.' and 'link' to add the link. 

                        Thanks,
                        Shaun 

  6. Brian Beauvais

    Feb 24, 2012

    Is there a way to show the total effort (number of days/hours/minutes) above the Sprint marker? This would ensure that we set the marker to the appropriate place based on the time we allocate for a sprint plan. We just started using this so I may be missing something completely.

    1. Brian Beauvais

      Feb 27, 2012

      It would also be nice to see the effort broken down by developer. This would be useful when setting up a sprint where issues are already assigned to developers and we are planning the sprint by adding issues to fill a predetermined number of developer hours.

      1. Brian Beauvais

        Feb 27, 2012

        it would also be useful to set the target number of hours for a sprint. For example, we plan our sprint for 13 development days X n developers. Showing where you are in relation to the target as you move the sprint bar would make sprint planning a lot easier.

        1. DELETED

          Mar 01, 2012

          I totally agree with Brian. The "Plan-mode" would be helpful to much more of our customers, if you could choose Story-Points or total hours. Not all Greenhopper customers are doing a 100% SCRUM, you know (wink)

          The total amount of time combined with bar showing the progress (just like the total estimate used in the Planning-Board) would be awesome too - before starting the sprint and while the sprint is running.

    2. Anonymous

      Mar 06, 2012

      I agree, this is a necessity to properly plan a sprint. 

    3. Markus Pulch

      Apr 16, 2012

      I fully agree... For us it is also a blocker to be able to work with estimations based on time.
      So it would be great if you could choose either Story Points or time based estimations. Are there any plans to go into this direction?

      1. Anonymous

        Aug 21, 2012

        For us it happened that we could not finish a story within the sprint. For the next sprint, we estimated the leftovers as Remaining. Still, the original estimate was calculated in the sprint marker. It is really annoying because I have to count manually the planned velocity. This is a blocker for us!!!

  7. Björn Wennerström

    Mar 30, 2012

    The new Sprint Retrospective view in 5.9.3 is nice, thanks. However, clicking on "View in Issue Navigator" reveals that the Sprint numbering is implemented as a global enumerator across all Rapid Boards, so even if you create a brand new Rapid Board for a new team with completely separate projects, the first Sprint will display as "1" in the Rapid Board but is stored as the global sprint nr +1. This will be highly confusing for any company with more than one Scrum team: we won't be able to display the Sprint value on JIRA issues and when writing JIRA queries to filter on Sprints, we'll have to keep that mapping in mind.

    It would be much better to implement sprint enumerators for each Rapid Board / team. But AFAIK Rapid Boards currently have no corresponding entities in JIRA. JIRA should have a team entity that the Rapid Boards relate to. 

    1. Shaun Clowes

      Apr 02, 2012

      Hi Björn, 

      You definitely can show the Sprint value on JIRA issues, it will be converted in to the name (rather than the ID) of the Sprint when displayed on the View Issue page or as a column in the Issue Navigator. 

      Thanks,
      Shaun 

      1. Björn Wennerström

        Apr 02, 2012

        Hi Shaun, right you are, the sprint name is used when displaying JIRA issues, but when you edit it's still the sprint ID that's being used. Even more confusing. Also, is there also a way to access the sprint name from a JIRA query? The query generated when clicking on "View in Issue Navigator" (sprint = id) from the Sprint Retrospective view seems to reference the sprint value... Such queries are needed for ex when creating confluence pages to easily display contents of sprints.

        You really should consider modelling teams that the Rapid Boards relate to. 

        1. Shaun Clowes

          Apr 02, 2012

          We don't plan on implementing mapping to Sprint names in the immediate future (though we will at some stage). An imminent release of GreenHopper will include links to the Sprint from the view issue page which will make this easier. 

          We're working hard to improve this area and understand your argument about teams. We're releasing significant new features every two weeks so we hope you'll be pleasantly surprised with some of the developments over the next couple of months. 

          1. Anonymous

            Jul 16, 2012

            Is there an issue open for this we can track?

            1. Rosie Jameson [Atlassian]

              Jul 16, 2012

              Please see GHS-4949 - Getting issue details... STATUS

               

  8. Anonymous

    Mar 30, 2012

    I cannot figure out a way to run multiple teams with the Scrum Rapid Board (related to Björn's comment above): It appears that only one sprint is allowed to be in progress globally - am I missing something?

    1. Shaun Clowes

      Apr 02, 2012

      Hi, 

      You definitely can have more than one Sprint active, however each board will not allow you to plan a new Sprint if some of the issues selected for the board are currently in an active Sprint. This will naturally never occur if Rapid Boards select different issues (for example one board selects project A and the other project B, or they select different components from the same Project) but if you have two Rapid Boards that select overlapping issues both will show any active Sprint on those issues.

      For clarity, if I have one board that selects all issues from project A and another that also selects issues from project A, if a Sprint is started on one board it will be visible on the other as well (since the same issues are present in both). 

      Thanks,
      Shaun 

      1. Anonymous

        Apr 03, 2012

        Hi Shaun,

        Thanks for the feedback.

        We have 2 teams working from the same project (single backlog) so we always have multiple sprints in progress.

        Having migrated from a different product (Agilo for Trac - effectively to Trac what Greenhopper is to Jira) there was more of a focus on configuring teams.

        There was then a 1:1 mapping of Sprint to Team so a team could only have a single sprint in progress at once rather than that being a constraint of a backlog.

        I appreciate this may more be in the Jira domain, but perhaps you could do something lightweight in Greenhopper to allow for this case?

        Thanks.

      2. Stefan Asseg

        Apr 07, 2012

        Hi,

        I can see why this limitation makes sense from some angles but for my team it presents an inconvenient limitation.

        See, we have longer sprints (1 month or slightly more) and within those we plan shorter iterations (1 week or slightly more).
        Currently we are doing this in the Planning Board where we set up nested versions where each short sprint is a child of a long sprint. We use the GH version sync feature to make sure issues in a short sprint are automatically in the corresponding long sprint as well.

        As we love the RapidBoard, my idea was to use two of them, a Product Backlog RapidBoard to plan the long sprints and a Sprint RB to plan the short sprints whereas the latter would display all issues of the current long sprint, so the issues that'd appear in work mode of the Product Backlog RB.
        I was expecting to be able to start one sprint per RB but as it turned out and as you've also confirmed in your comment, this isn't possible because the two RBs contain overlapping issues.

        As far as I can tell the Sprint field currently does contain multiple sprints for an issue, namely all the sprints the issue was planned for. But apparently an issue can't be in two active Sprints at the same time.
        Am I right that this limitation is not a technical one but rather enforced on purpose?

        Any chances to drop this limitation so an issue can be in multiple active sprints at the same time?

        Cheers,
        Stefan

      3. Anonymous

        Jul 12, 2012

        We have a ton of issues across one project that we would like to have different dev groups sprint on at once.

        1. The natural planning perspective is to include all of the open eligible issues in the project
        2. Then add a set of those to a different sprint for each group of devs

        I tried a simple quick filter to inline exclude open sprint issues hoping based on your comment that would fix it, but since the root rapid board still includes open sprint items no luck (sad)

        Its kind of a horrible pain right now as to have concurrent sprints we need each rapid board to exclude all open sprints. But they have to be specified uniquely since if we did all open sprints the rapid board would never be allowed to open one itself... I am not sure what the reasoning is to tie only one sprint to a query. I can see excluding from planning automatically those issues that are already in an open sprint, but I don't think it should also prevent you from creating a new sprint just because the rapid board itself might include open sprint items in the query.

        1. Shaun Clowes

          Jul 13, 2012

          There are several different ways you can make this work. My personal favourite at the moment is to have one board for planning (that all teams use), then separate per team boards. For example, the filter for the planning board might be like: 

             project = x and labels is empty 
          This board can be used to plan a sprint. Once you have the sprint you want you can use the "View in Issue Navigator" link from the Sprint Report to label all of the issues for the team that is doing them (for example "teama"). This will cause them to disappear from the planning Rapid Board. You can then have a rapid board per team: 
             project = x and lables = teama
          These boards can then be used by the teams to execute and track their sprints. 
          You can get more clever though. For example this query would give a Rapid Board that only shows issues that are not currently in a sprint, or that are explicitly marked for teama: 
            project = x and ( (Sprint not in openSprints() or sprint is empty) or labels = teama )
          So you could use plan mode to pick the issues, label them for teama then go ahead and start the sprint. 

  9. Björn Wennerström

    Apr 03, 2012

    Agreed, the status would be much more useful to show than the priority. Ideally let us configure which columns to see as on the Planning Board. Minimal solution: use the strikethru notation to denote closed issues, i.e. NERDS-2398

    As MS would say: why would you want to have multiple sprints in the same rapid board?

  10. jessebs

    Apr 13, 2012

    Two things for the Scrum functionality:

    Burndown Chart - Offer the ability to do it more than just for the current sprint.  Whole project would be useful.

    Make it possible (or easier if it is possible b/c I havent found it) to start throwing more stories into the current sprint if the work for the sprint finishes early.

    1. Stefan Asseg

      Apr 13, 2012

      Adding issues to the current sprint is possible in the latest version of the RapidBoard. Just pull them up into the sprint in Plan Mode and you're good.

      1. Jean-Pierre Chiri

        Apr 20, 2012

        Could i do it on JIRA 4.4 GH 5.8.7 ?

         

  11. Elena Leonova

    Apr 24, 2012

    Could you please suggest how to use GreenHopper Labs for multiple teams?

    How to plan work for them separately?

    Thanks

    1. Shaun Clowes

      Apr 25, 2012

      Hi Elena, 

      There are many ways to achieve this. If the issues can be easily separated (for example, they are in different projects or use different components, labels or any other field on the issues) just create two Rapid Boards, one for each team, with a filter that selects those issues. 

      Alternatively, if you wish to work from one backlog but with two teams, try having a Planning Rapid board and two work Rapid Boards. The planning Rapid Board should have a filter which includes "and ( Sprint not in openSprints() or updated > -60m". This will create a board which never has any Sprints in Work mode except for the first hour following a Sprint being planned. So you can go ahead and plan the Sprint then use work mode to label the issues for the right team. The two work Rapid Boards for your teams then just filter for the labels you use. 

      Thanks,
      Shaun 

  12. Anonymous

    Apr 24, 2012

    Though I have added my project I do not see all the tickets from the project displayed in the SCRUM plan mode. I am not able to select the tickets as they are not displayed. Is there any reason why I am not able to see my tickets in the plan mode ? 

    I created a custom filter with the tickets I need for the sprint as well. This does not help either to view my tickets in the Plan mode. 

    1. MarkW

      May 01, 2012

      I too have created a custom filter but unfortunately plan mode is only visible using the scrum template.

      Why do I need Plan mode using filters?

      Our use of JIRA is not a development project per JIRA project.  Our JIRA projects are grouped by Application or Product Suites which means multple projects (versions) listed. This means that more than one sprint needs to be ran. So if Filters can use the planning board then I can split my projects (versions) into filters and use the plan board.

      Unless I am completely going about this the wrong way?

      Ignore - I found an alternate method to filter in the board configuration.. I also found the following article: https://answers.atlassian.com/questions/45095/start-multiple-sprints-simultaneously

  13. Anonymous

    May 07, 2012

    Hi,

    I installed Jira 5.0.4 together with Greenhopper 5.9.6 and then created a SCRUM Rapid Board. I get the message "Scrum for Rapid Board is currently unavailable. An administrator must perform a re-index before you can use Scrum for Rapid Board functionality.".

    After that I reeindexed, but this did not fix the issue. (Deleting the Rapid Board and creating new ones didn't either) Any idea what else I can try?

     

    1. Anonymous

      May 09, 2012

      Same problem here. Re-indexing did not work as well as removing and recreating the board.

      Even tried it with a new project. I wonder if some prerequisites in configuring the system have to be made.

      Project is enabled for greenhooper and uses the scrum template. Board was created with scrum prerequisite. The filter shows the wanted issues and when configuring the columns of the rapid board it shows the according number of issues in each state (open, reopened) and so on. The only thing missing is the view of the rapid board. 

      So any clues what to look for?

      Best regards!

      1. Shaun Clowes

        May 10, 2012

        Hi, 

        This message is generated when the Rapid Board can tell that one or more of the issues in the board does not have the Sprint field associated with it. There are a few reasons this could happen:

        • The re-index was not completed successfully 
        • The Sprint field is not associated with all issue types in all projects (which is done in the "Custom Fields" section of the Administration interface)
        • The Sprint field is 'hidden' by a field scheme that has been applied to the project (which is done in the "Field Configuration" and "Field Configuration Schemes" section of the Administration interface)

        Please check if any of those conditions are the problem. 

        Thanks,
        Shaun 

  14. Anonymous

    May 07, 2012

    Hello, I would like to be able to close out a US for a Sprint even if the sub-task is not closed.  We track our Doc work for a US with a Sub-Task.  However, for our Scrum processes, when Dev and QA are finished with a US, then the US can be closed.  Unfortunately, the Rapid Board will not let me move forward at all with the Sprint as I have USs with sub-tasks still open. 

    1. Shaun Clowes

      May 07, 2012

      Hi, 

      I'd suggest just creating a new user story for the doc and moving the sub task to be tracked under that story (or just using the story itself). 

      Thanks,
      Shaun 

      1. Anonymous

        May 08, 2012

        This will work for a short term solution.  However, our normal process is to have the doc work be a sub-task of the US.  Therefore, it would be better if Greenhopper allows me to close the Sprint with open sub-tasks if I would like. 

  15. DELETED

    May 09, 2012

    Sad thing, there is still no option to sum up all estimated hours and show them on the sprint marker (sad) - is this feature still discussed or already dead?

    1. Shaun Clowes

      May 09, 2012

      Hi Dominic,

      I don't know why you would assume it's 'dead'. We are releasing huge portions of new functionality every two weeks. 

      Regarding hour estimates, we will shortly release functionality to sum the original estimates of the issues in the marker. 

      Thanks, Shaun

      1. DELETED

        May 09, 2012

        Hey Shaun,

        thanks for the update. I just asked because there were no news about this feature since the 1st of march. It's awesome that this feature is coming soon! Our customers will be very very pleased with this. (big grin)

      2. Stefan Asseg

        May 09, 2012

        The original estimates? Are you sure this is a good idea?

        Consider following scenarios:

        Scenario 1:

        • An issue has an original estimate of 10 days.
        • The team works 5 days on the issue in the current sprint.
        • The team discovers a bad bug somewhere else in the project and decide that fixing that bad bug still in the current sprint is far more important than completing issue X as planned.
        • The sprint gets finished and the issue returns to the backlog.

        -> Problem: The issue now takes up 10 days of the team's valuable time for the next sprint in Plan Mode but actually, only 5 days of work have to be done to compete issue X (given that the original estimation was realistic).

        Scenario 2:

        • Issue X has an original estimate of 5 days.
        • The issue's estimation was too optimistic and gets updated to 15 days before the next sprint is planned. To learn from their estimation mistake, the team doesn't update the original estimate but rather documents that they were 200% off with their initial estimation.

        -> Problem: The issue now only takes up 5 days of the team's time in Plan Mode but actually, 15 days of work hide in that issue.

        You get the idea. I'd strongly suggest to display the remaining estimate rather than the original estimate.

         

        Cheers,
        Stefan

        1. Shaun Clowes

          May 10, 2012

          Let me first say that GreenHopper releases every two weeks, we bite off bits of functionality at a time and release it. We've released 37 different major features in the past year, so talking about something that is two weeks away doesn't preclude a whole bunch of other stuff happening a month from now. 

          Regarding Original Estimate, yes, that's our plan. At the moment the burndown chart only burns down the value when the item reaches done. Using the Original Estimate to drive burndown is quite useful and you don't need to update Remaining Estimate each day. 

          More broadly, we're trying to introduce a distinction between estimation (which is used for measuring the size of a backlog and calculating velocity) vs tracking (which is often the burndown of hours used during the Sprint to be sure we're not way off the pace necessary to complete the stories in the Sprint timebox). 

          Product teams often need to be able to estimate how long a product will take to deliver. This is tough because the backlog may stretch many months in to the future so the team can only provide a very rough estimate in conditions of uncertainty without wasting days breaking the work down. However, from Sprint to Sprint as they work through the stories the team will develop a cadence of completing <x> units of work they had 'rough estimated', i.e. their velocity. This is one of my favourite outcomes of Scrum because it means that we can relatively accurately estimate how long portions of the backlog will take to get done with simple rough estimates that we can get way before we even consider doing them. However, to make this work we need to estimate stories with a similar level of uncertainty. We also need to track the amount of estimation units we have actually fully completed from Sprint to Sprint because this number is the one that tells us with relative certainty how much we can fit in to each future Sprint and have conviction that they will all be completed. 

          So looking at your scenario one, the experience of the blocker bug that reduced the teams ability to get the work done is unlikely to be an isolated occurrence. While it might not happen every Sprint it will happen every now and then. From a certainty perspective this means that the team cannot look forward in a backlog and really commit to completing a 10d story in a Sprint (because unplanned stuff gets in their way). You're right that this might cause them to under commit in the next Sprint, but it certainly means you could not look 5 sprints ahead in the backlog and say they would complete 5 x 10d stories. It wouldn't even be right to say they could do 5d each Sprint because in Sprints where they don't get interrupted they would do more. By only counting stuff you actually completed then taking the average from Sprint to Sprint you can look forward in the backlog and believe with some certainty you could get that amount (of complete stories) done each Sprint. By only using the original estimate (rather than a remaining estimate or an updated estimate) you can be sure that the estimates of all of the items in the backlog have the same level of uncertainty, if some are more accurate than others this will change your velocity so that it is no longer useful looking far out in the backlog at definitively uncertain items. 

          In terms of under committing, this will only tend to happen in the early Sprints before you have established a good velocity. In your first scenario that's definitely the case but the team could correct by dragging another story in to the second Sprint when (and if) they run out of work. 

          This approach to estimation ties in well with your second scenario. The inaccurate estimate of 5 days is not going to be an isolated occurrence, in fact the estimates are always going to be wrong (some very little, some wildly so). As long as the team estimates the same way across the whole backlog this will work it self out over time. For example if they always underestimate they may find that for a 10 day sprint with 4 team members they can only really commit to 20 days of their estimation unit. If they have established a stable velocity this has no effect because from a planning perspective we can still estimate how much work we'll get done in upcoming Sprints with good certainty. 

          The net net of this overly long comment is that with an established velocity the original estimate is going to be a better predictor of the work you can actually do than the remaining estimate.

          However, we will be enabling the use of remaining hours in burndowns shortly since many teams use it to track Sprint progress. It may make sense to enable the remaining hours to be used as an estimation statistic but it's not in our immediate plans. 

           

           

          1. Stefan Asseg

            May 10, 2012

            Shaun, thanks for the quite stretched-out comment.

            What you wrote makes sense, especially when considering that a Scrum team's goal should be to figure out what their velocity is and to be able to plan sprints accordingly.

            However, I can tell you that some teams just don't have the freedom to always plan a sprint according to what their velocity tells them they can get done but there might be influences from outside the team that simply don't respect that Scrum mentality (which, needless to say, is bad but sometimes changing this is a longer process). Under such circumstances I think it would be very helpful to have the remaining estimate calculated for the stories in a sprint.

            So in order to server both types of teams (the lucky and not so lucky ones (wink) ), it'd be great to be able to choose what exactly you want to have summed up in your sprint marker.

            Thanks,
            Stefan

  16. Omar PS

    May 09, 2012

    Hi,

    Do you have plans to incorporate the Sprint filter on the other Greenhopper boards like Planning and Task?

    Best Regards,
    Omar

    1. Shaun Clowes

      May 10, 2012

      Hi Omar, 

      No, we do not plan on moving this functionality to the other boards. We will eventually retire the existing Planning/Task/Chart and Released boards in favour of the Rapid Board. 

      Thanks,
      Shaun 

      1. Omar PS

        May 10, 2012

        Ok, I think it's better to have all these integrated in a single board that supports both single and multiple projects.

        Those existing boards have some visualization features that I like a lot, like different card visualizations, custom card styles, etc.

        I hope these features will be migrated to the Rapid Board.

        Best Regards,
        Omar

        1. Omar PS

          May 10, 2012

          I just want to point out that the Planning and Task Boards make me feel like if I were using sticky notes, this not happens on the Rapid Board.

           

          Best Regards,
          Omar 

  17. Justin Leader

    May 19, 2012

    Hey!  I love the rapid board and we're using it throughout the company now, but we don't use versions or releases.  So how can i build widgets with JQL if i can't say "sprint 3 on Rapidboard "Programming Team""  ?  Does this exist?

    1. Stefan Asseg

      May 20, 2012

      Hi,

      The information "on Rapidboard "Programming Team"" isn't stored with issues but the RapidBoard "Programming Team" has a filter which selects the issues the RB displays. So to get exactly the issues displayed in that RB you could write the JQL query "filter = <ID of filter for the "Programming Team" RB>".

      Cheers, Stefan

      1. Justin Leader

        May 20, 2012

        I actually have each rapid board using mainly a component to determine what appears in the rapidboard or not, so I don't have any trouble finding those issues. But the problem isn't finding issues that appear in the RapidBoard's filter, but specifically finding issues that the team is working on right now.  Because right now I have almost no ability to report on RapidBoard sprints... I want to create a custom hour-based burndown chart, but I can't because I can't filter for issues that are in the current rapidboard sprint. I can't create automatic display of points and hours completed in previous sprints... there's so little I can do with any of this data that my team has been questioning me on where all the great reporting was that I promised them JIRA would provide!

        1. Stefan Asseg

          May 20, 2012

          That's even less of a problem, just use the JQL "Sprint IN openSprints()" which gives you all currently open sprints. And as there can always only be one sprint per RapidBoard you should be good if you filter for the issues of e.g. the component that the RapidBoard displays. Is that what you've been looking for?

          Cheers, Stefan

          1. Shaun Clowes

            May 20, 2012

            That JQL absolutely right Stefan.

            One thing to note though, "there can always only be one sprint per RapidBoard" is not quite true. While you cannot use Plan mode to start another Sprint on a board that is already showing one, if a Rapid Board includes issues from multiple different Sprints they will show up in work mode just fine. This is useful for Scrum of Scrums style approaches where multiple teams run separate Sprints but they are rolled up to be viewed across both as well. 

            Thanks, Shaun

  18. Anonymous

    May 25, 2012

    Hello to everybody, we are using Scrum for quite some sprints and we really like the flexibility. Only one question: is it possible to customize the plan mode view by changing or adding some more fields? We really miss labels and categories.

    Thanks and Regards

    Ross

  19. Anonymous

    Jun 18, 2012

    Hello, we have just started to use GH and are also new to SCRUM. So far, we are liking it. We are using the Rapid Board for the planning exercise and it is definitely amongst the best tools we have tried for this.

    I have a question though. Is it possible to define the sprint goals and record it in GH. It would be useful for the product owner and the team to see the goals in GH during the planning. During the demo also, it will be helpful as GH can be used to drive a presentation for the audience. Maybe this can be stored on the grey sprint marker.

    Thanks,
    Andy

    1. Nicholas Muldoon [Atlassian]

      Jun 19, 2012

      Hi Andy,

      You may like to look at Viewing the Sprint Report and Viewing the Velocity Chart - these will show your sprint goal and what was actually delivered over time.

      Thanks Andy,

      Nicholas Muldoon

  20. Pål Werdenhoff

    Jun 26, 2012

    Hi Greenhopper!

    Our company is using Greenhopper, and have for some time. We are using it for scrum and kanban projects, and really appreciate all the hard work you put in (smile)

    I have a couple of questions I hoper you're able to answer.

    1. I can see there's a couple of registered issues, asking for swimlane constraints, and a single constraint covering more than one column. Any chance you can tell us more about what your strategy is for supporting more flexible WIP limits?
    2. I currently have a couple of projects working on the kanban board. All issues are currently kept within the board, even though they have been released to production. I'm doing this to preserve the data for reporting. Is it possible for the report charts to show me data that no longer live on the board? If not, what strategy should I use to prevent the board from being cluttered and unresponsive?

    Thanks and keep up the good work

    Pål

    1. Shaun Clowes

      Jun 26, 2012

      Hi Pål,

      1. We haven't decided what we will do here yet but we understand it's an often requested feature. 
      2. In recent versions of GreenHopper there is a separate 'work mode sub filter' for Kanban boards. You can use this to filter out issues from work mode that will still appear in the reports. For example you could filter out issues that were resolved more than a week ago with "resolved < -7d"

      Thanks,
      Shaun 

  21. Lara Fields

    Jul 11, 2012

    We are just starting to use the Rapid Board, and one thing that has come up as a problem - We are using a custom field for our estimation, and we had to break a single story up into two stories. The estimation value and sum shown in the Report view now shows the ORIGINAL value for the first story, not the new value generated as a result of the break up. Clicking on the story itself in the Work mode shows the correct estimate value. Running a re-index does not fix the report value. Moving the story out of the sprint, and then back into the sprint does not fix the report value. Changing the estimation field and then changing it back does not change the report value.

     

    1. Shaun Clowes

      Jul 12, 2012

      Hi Lara, 

      This is expected behaviour, the Sprint Report will show the estimate for the story at the time it was first added to the Sprint. I've never really thought about this approach of splitting a story during the sprint, this is most often done before the sprint because the story is too big to fit. 

      For this case you could just move the original story out of the sprint and close it, then create another different story for the other half of the issue (in addition to the other new story for half the issue you've already created). 

      Thanks,
      Shaun 

      1. Lara Fields

        Jul 13, 2012

        Hi Shaun,

        Thanks for the reply - The close / create two new stories is a workaround, but then the story is marked as "added after the sprint", which also isn't the case. I think one of the areas that is proving difficult, is it is great in theory to say "Ok, now GO!" at the beginning of a sprint, and have everything from that point forward fixed in time, however in practice that is rarely the way things go. It doesn't allow for mistakes, typos, someone forgetting to update the story with the correct points if a point of contention is resolved the day before the sprint start, etc. I would really like to see marking information as a "scope change" be optional - sometimes it isn't a scope change, it is just the nature of running a sprint. The splitting a story is a use case that we have run across multiple times - not because the story it too big, but because something else strategically important has to be pulled in after the sprint has started, and so something else must be pulled out. Sometimes that results in a reevaluation of the existing stories to determine if the functionality can be staged across two (or more) sprints. This particular story was something that was already being staged out over multiple sprints, and as a result of a time-critical issue, was the only piece that could realistically be pulled (and we only needed to pull half of it)

        We are loving the new board in many ways, in other ways there are things that hinder our process - just some food for thought for your team as I know this is under very active development. A couple of other ways that our process works for us where the new board is awkward:

        1) Proportional layout of the Plan mode - it is great when looking at as a single person on a laptop screen, but during our planning meetings, we are all sitting around a single very large wall screen - the layout favors the list of stories in the backlog, rather than the descriptions of the stories in the right panel. This leaves a lot of empty space, and makes the stories difficult to read. We tried using the browser zoom as a workaround, and the layout gets completely broken.

        2) Global backlog - we have a ton of things in the backlog that have competing interests / categories that have nothing to do with the components. Since the ranking in greenhopper is global, we need another way of grouping them, because they really only rank against other stories in the same "bucket". We work around that by grouping in nested fixVersions - we have a "Backlog On Deck" that is where we pull the top "these need to be discussed for inclusion in the next sprint", and put things back to. That worked great when we were using the fixVersion to break out the sprints, but now is very awkward to manage (workable, but awkward). If you have any suggestions on what to differently there, I'm all ears - it would be nice to be able to have a configurable transition or hook (moving out of a sprint sets field x's value to y, moving into a sprint set's field x's value to z).

        3) We use subtasks heavily, which have their own pointing system (since they affect different team resources). We would really like the ability to see those values in the subtask form - I realize from earlier posts that you went with "easier" rather than "more configurable" - but a screen scheme for the right-hand panel in task mode would be very helpful.

         

         

         

  22. Justin Mitchell

    Jul 20, 2012

    Hello, We have been using GH for a while and love all of the new functionality you have been adding to the rapid boards recently.

    With the update that allows us to track sprints without using fixVersion we would like to reorganize all of our sprint data into a single board to make better use of the reporting built into the rapid board. We had been creating a new rapid board for each sprint but are now changing to use one rapid board for backlog and another for tracking all sprints. As we started doing this we noticed some errors in our past sprint data.

    Is there a way currently or planned in the future for an administrator or sprint owner to edit past sprint data?

    Some of the things we would like to fix are: the Sprint name that is associated with a Sprint ID, the start/end date of a completed sprint, and what stories were on the sprint when it started.

    Thanks,

    Justin

    1. Shaun Clowes

      Jul 23, 2012

      There are no current plans to allow editing these fields in the UI, but you can definitely do most of this (i.e Sprint name, start and end date) by editing the AO_60DB71_SPRINT database table. 

      Editing the issues in the sprint is much harder because you have to edit the issue history, still possible though. 

      If you go this route please be sure to make extensive backups of your data. 

      Thanks,
      Shaun 

  23. Markus Pulch

    Aug 20, 2012

    Is there any option to use the Remaining Estimate instead of Original Estimate?

    Use Case: a story with Original Estimate of 20h was not finished within a sprint (Remaining Estimate is 4h). While finishing the sprint the story is added to the top of the backlog and shown as 20h. For sure this has an impact on the Team commitment.

    Also it would be great if the time of subtasks would be aggregated within the parent on the planning view.

    Is there any option to change this behavior? If there are subtasks existing then in ideal case it should show the aggregated Remaining Estimate. So it would be great to have an additional option of 'Remaining Estimate' in the 'Estimation Statistic' dropdown.

    I fully understand that subtasks are not shown on the planning view and it make sense to hide them. Also it makes sense to use the 'original Storypoints' and not counting them down for the next sprint. But If you use 'time' as base then remaining time is the only time you are interested in for planning and burndown chart.

    Are there reasons for using  a) the Original Estimate and b) not aggregating the time of subtasks? Maybe we use the system completely wrong...

  24. Pat Herlihy

    Aug 29, 2012

    Hi,

    Firstly I would like to say what a fantasic product GreenHopper is - I can't imagine using JIRA without it.

    Our software development team work on large well documentated change requests (CR) and estimates based on difficult. They break the CR down into multiple Tasks and estimate the Tasks.

    So far we had the CR as a User Story and add Sub Tasks for the Dev Tasks. We currently use the Kanban Board and use Fix Versions for Sprints/Iterations. So we could have a User Story for 20 points and work on it over several iterations. We plan to do 6 points in 1 Iteration and when complete they are counted as Velocity in that iteration.

    We would love to use the Scrum Board but can't at the moment due the to restriction on Sub-Tasks and the fact the points would appear to be allocated to the User Story and not counted for Velocity until the User Story is complete.

    Do you plan is having full support for Sub-Tasks (as objects on their own) on the Scrum Plan, Work, Report modes?

    I assume the Kanban Board will not have the same reporting as the Scrum Board - as it's the planning and reporting that makes the Scrum Board stand out now.

    Thanks in advance

    Pat

  25. Jamie Wardlaw

    Sept 21, 2012

    Hi there,

    The parallel sprint lab is proving to meet my needs well, it is almost there in allowing me to work in the '"classic" way for planning that I had always followed with only a few remaining constraints that if they become overwhelmingly frustrating I will pass on to you guys.

    I have for a long time wanted to get a good wallboard up and running out of the box, but never quite found I was happy with the default offerings on gadgets. With no time to develop my own could you comment on how difficult it would be to extend the existing Greenhopper Wallboard Gadget to cycle through all active sprints on the selected board (now that parallel sprints can be scheduled) or alternatively add a field that would allow us to select the sprint to be displayed from a set of parallel sprints (simply adding multiple gadgets would then acheive the same end function). 

    1. Shaun Clowes

      Sept 23, 2012

      It wouldn't be too difficult but we don't plan on addressing the gadgets in the imminent future. Because parallel sprints are a labs feature we would probably re-implement the functionality to be able to group the sprints logically together (for example, by team) before we made any changes to the gadgets. 

      Thanks,
      Shaun 

  26. Anonymous

    Oct 05, 2012

    Hi Shaun,

    I just wanted to know if there is any way to show the names of people working on a task in the cards in the scrum board?

     

  27. Anonymous

    Oct 25, 2012

    Hi,

    I only see the Parallel Sprints option in Labs. I want to activate Epic creation from Greenhopper but not sure how.

    Thanks for the help.

    1. Nicholas Muldoon [Atlassian]

      Oct 26, 2012

      Please make sure you are using GreenHopper 6.0.6, you can find the version number in the footer. 

      Thanks,
      Nicholas
      @GreenHopperTeam 

      1. Anonymous

        Oct 29, 2012

        I'm using OnDemand JIRA. I don't believe I can upgrade myself, correct? If so, when will this feature be activated?

        Thanks.

        1. Rosie Jameson [Atlassian]

          Oct 29, 2012

          We anticipate upgrading OnDemand to 6.0.6 within the next fortnight. Please watch this page: GreenHopper OnDemand Release Summary

  28. Will Harris

    Nov 27, 2012

    Is there any information about the level of stability of particular Labs features, or how close features are to making it out of Labs?

    I don't mind if the functionality changes - I'm more worried about DB-level changes that might mean I lose work if I adopt Labs features too early...

  29. Anonymous

    Nov 27, 2012

    Was the epic option in the Greenhopper lab page removed for GH 6.0.8?  I see parallel sprints and analytics, but not epics.

     

    Thanks.

    1. Rosie Jameson [Atlassian]

      Nov 27, 2012

      Epics are still in Labs in GH 6.0.8

  30. Chris Micacchi

    Dec 05, 2012

    I tried to enable the Epics labs (we are using OnDemand), but when enabled, all rapidboards don't load and instead give this error:

    Error

    Index: 1, Size: 0

     

     

    1. Chris Micacchi

      Dec 05, 2012

      Also, for whatever reason, the "Epic Label" field has been added to my custom fields nine times (I've attempted to delete all the duplicates, but they seem to reappear).

      1. Rosie Jameson [Atlassian]

        Dec 10, 2012

        Can you please contact http://support.atlassian.com ? Many thanks

  31. Paulette Martin-Elliston

    Jan 12, 2013

    We want to use a multiple board approach to manage the Business Analysis activity as well as the development activity, with the main backlog common between both boards.

    Main Board: where Project = X;  BA Board where Project = X and Label = 'BA'

    We have started Sprint 1 on the main board and have set up a simultaneous sprint on the BA Board to track the preparation of the upcoming Sprint 2 items with an end date 1 day before the proposed start of Sprint 2 - and the BA sprint contains the actual workitems that are planned to be put into Sprint 2.

    The question is:  Once the BA sprint 2 preparation has finished, will these workitems still be available in the main board to drag into a development sprint 2 - or alternatively will they disappear from the Main Board plan view as they were contained in a sprint that is now closed???

    I hope they would still be available in the Main Board view, to be dragged into the new Sprint 2.

    1. Shaun Clowes

      Jan 13, 2013

      It depends on the columns configured in your board. 

      A board decides the issues to show using a fairly simple process: 

      • Find all issues that match the filter for the board 
      • Check that the issue is in a status that is mapped to a column of the board, if not it will not be shown in the board
      • If the issue is in a status mapped to the last column of the board, it's complete and will only be shown in the reports (i.e. it will not show up in Plan mode) 
      • If the issue has the sprint field set to a sprint that is still open, show the issue on work mode, otherwise show the issue on plan mode 

      So in your situation the if the last column of the BA board is not the last column of the main board, then the issues will reappear ready for planning again. 

      Cheers,
      Shaun 

  32. alan lippa

    Mar 29, 2013

    is there any dates on deploying release planning to on-demand customers, this is a really great feature we have been asking about for sometime and now just happen to run into this doing some research.

     

    Any deployment dates?

     

    thanks - Al

    1. Rosie Jameson [Atlassian]

      Apr 01, 2013

      The exact date is being confirmed, but please expect it in the next OnDemand update. Thanks for your patience.

  33. Andre Brissette

    Apr 02, 2013

    We are on JIRA OnDemand so I did not used the Version Planning yet but here is two early comments regarding the design of the feature.  

    First, on the usability side I am not sure it s really user-friendly to "stack" another column on the left with EPIC.  With the details section on the right and the Epic on the left, I felt the screen was already pretty full.  

    Second comment is more conceptual related.  In Scrum usually we see a Version/Release more like the outcome of a series of Sprint, not like a tag on specific Story.  Of course the actual version field of a Story make a lot of sens (I still use it a lot) to identify when a Story has been delivered.  But in planning it's very different thing in my mind in Scrum.  If I have a release on next June 1st, I can for sure guarantee how many Sprints will be in it, but which Stories will be part of it is more a wish than anything else.

    Did the GH team evaluate the option to base the concept of version on a set of Sprint in the Scrum Board  ?  Regarding usability, would it be better to implement version as another level of marker ?  Like a parent marker that contain multiple Sprint ?

    thanks

     

    1. Tom Kotecki

      Apr 26, 2013

      Hi Andre,

      Thanks for your feedback. We realise another column might take too much screen real estate for you, which is why you can easily close the detail view on the right, or the Epic panel on the left - and thus reclaim some space.

      As for conceptual mapping, we spoke to a number of customers and each team manages versions differently. Some will have what is effectively a 1:1 sprint to version mapping, some will have many to one like you describe, and most will have exceptions (so say a bugfix to a 1.x branch will have a different version assigned to it than new features which will ship in 2.x branch, even though they have all been worked on during the same sprint). We wanted to support all of these options, which is the reason we opted in for full flexibility.

      Hope this helps

      Tom Kotecki

      1. Andre Brissette

        May 03, 2013

        Hi, is there a way to disable the new version feature in the rapid board ?

        I understand it may be useful for some team but for teams who do not need this feature it really lower the cleanliness of the screen. For example, many team use the 'fixversion' field to configure the filter of their rapid board. Result is that they end up with a repeated and useless version label on many line in their board.

        My opinion is that before this addition the rapid board design reach a unique balance of clarity and quantity of useful information. I feel this forced addition is challenging this balance.

        by the way, is it the right place to give that kind of feedback ?

        thanks,
        Andre

        1. Paul Alexander

          May 03, 2013

          When collapsed, Andre, the Versions and Epics labels only utilize ~15 pixels on the left margin. Have you tried that?

          1. Andre Brissette

            May 03, 2013

            Hi Paul, I agree that the Version label in the left margin is fine.  My problem is with the fact that now the version name is displayed on every row in the list of issue and it s useless for us.

            thanks

            1. Paul Alexander

              May 03, 2013

              I stand corrected...

  34. user-76a27

    Apr 12, 2013

    We've enabled Release Planning for our JIRA instance, but right away we have projects that don't use versions complaining about the lost real estate on the issue "cards", where the version (or version count) is displayed.

    It would be great if this specific feature could be enable per project, or if the card content was configurable (or both, of course).

    If there's an existing was to work around this, I've not been able to find it and I'd be interested in hearing ideas.

    Thanks.

    Tom

  35. alan lippa

    Apr 12, 2013

    I would just be thrilled to engage fixversion like "epic" in GH that is forthcoming from the lab But just as important -> to allow priority rather than ranking as the sorting parameter....the tool used to support the priority field for scrum boards but now you have to have ranking to make a sprint and we use priority not ranking so this is frustrating....

    Tom - have you checked out the ability to customize the view of the card presented?

    Cause custom card views are very much possible in GH!

    If you go top right and click on the drop down to get to configure, then from configure choose the last tab, and choose "Issue Detail view" you can change and augment in GH what is seen on the card detail view including this lost function of yours....

    1. user-76a27

      Apr 12, 2013

      It's not so much the Detail View that's bothering people, but the one line "summary" that includes the issue key and as much of the summary as will fit. This same space is shared with a label for the Epic Name and now the Version, and it's these labels that eat into the space that more summary text would normally occupy. The various Configure tabs don't seem to cover the "card" contents, but only the Detail view, which has considerably more space.

      I've seen other open issues where people are requesting "card" customization, and there seems to be a certain amount of resistance to that on the part of the developers, perhaps inspired by a desire to keep them minimal. In this case, I actually want less on the card rather than more, but either way it does not yet seem to be configurable, like the Detail View is.



Log a request with our support team.



Raise an issue for our developers.



See answers from the community.



Tweet, blog and update our documentation.

Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 2.5 Australia License.