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

Background

The board you see today is a fresh start for GreenHopper. We built it to take advantage of the latest in web technology and provide you, the customer, with an awesome experience for planning, tracking and reporting on the progress of your agile projects and teams.
 
One thing is absolutely clear: your agile project does not necessarily map to a single JIRA Project. For that reason we have addressed the most common feature request — GHS-1800, support for more than one JIRA project in GreenHopper. Not being folks to sit still, we took this opportunity to introduce a new user experience with fewer page reloads and more useful URLs —  users can have a URL for the displayed page (GHS-990).
The new board is extraordinarily flexible due to our use of the JIRA Query Language (JQL) — you can show many projects or one project, based on whatever filter criteria you choose.
 
Further, the board has returned the Fix Version field back to its intended use-case, showing which versions a bug or story can be found in. The board has resulted in a decoupling of Sprints from the Fix Version field (GHS-945). The Fix Version field is now available for release planning via the Versions panel in Plan mode.
 
We also have a new ranking field, Global Rank, which provides better performance than the previous solution. For the first time, you can now rank issues across JIRA Projects.
 
With the introduction of the Global Rank, JIRA and GreenHopper no longer need to reindex all of the issues in each JIRA Project every evening (GHS-2727).

 

On this page:

Related pages:

How is the new board different from the Classic Planning/Task/Chart/Released Boards?

The new board is very similar to the Classic Task Board with a few significant differences:

  • support for multiple JIRA projects
  • swimlanes
  • control chart for measuring the cycle time
  • interactive charts (zoom and click)
  • permanent links provide 'what you see is what they get' when emailing or IM'ing URLs
  • quick filters are based on JQL so you can create your own

Over time the new board will continue to evolve to replace the bulk of the functionality on the Classic Planning/Task/Chart/Released Boards.

The plan

The board (previously known as the "Rapid Board") graduated from Labs in GreenHopper 5.8, initially providing support for Kanban teams. Scrum functionality was then introduced in 5.8.5, and graduated from Labs in 5.10. Epics were added in  6.0.6  and graduated from Labs in 6.1. Versions were added in 6.1.4 and graduated from Labs in 6.2.

In 6.0 we moved the existing boards (Planning, Task, Chart and Released Boards) to a Classic Mode, and dropped the "Rapid" title for the new board. The existing functionality on the Classic Planning, Classic Task, Classic Chart and Classic Released Boards will continue to be available in all releases up until at least November 30, 2013. We will provide a further update closer to that date.

We are focusing our development efforts on expanding your planning options. Our intention is to provide a very fast and easy approach to building a backlog, grooming the backlog then executing Sprints. We will continue to seek feedback from new adopters as we develop the functionality.

What now?

If you haven't yet tried the new board, we encourage you to give it a go.

Please note:

  • Contexts are replaced by boards; there is no migration path today so if you are already using GreenHopper then you will need to recreate these from scratch.
  • No labels

151 Comments

  1. Christopher Lichti

    Jan 31, 2012

    Are there any plans to support XP teams?

    1. Nicholas Muldoon [Atlassian]

      Feb 01, 2012

      Hi Christopher,

      Thanks for the query.

      GreenHopper certainly supports XP teams today. While we talk of Scrum teams a lot of the same rules apply for XP. For example, GreenHopper will:

      • assist your team in capturing user stories and conducting iteration planning
      • measure your teams velocity

       One area where we do let an XP team down is the pair programming aspect. GreenHopper does not provide the ability to specify multiple assignees - there are a few workarounds.

      If I have missed something please let me know and I will investigate further.

      Thanks Christopher.

      Regards,
      Nicholas Muldoon 

      1. Ian Brandt

        Jun 18, 2012

        Hi Nicholas,

        The current Planning Board supports XP's tiered Release and Iteration Planning practices by way of hierarchical versions.  Per GHS-5151 - Getting issue details... STATUS , which is resolved as Won't Fix, hierarchical sprints are not planned for the new Rapid Board.  How will the Rapid Board support the Release Planning practice of XP otherwise?

        Thanks,

        Ian Brandt

        1. Anonymous

          Aug 29, 2012

          Ian, I completely support your comment. I totally annoys me that Atlassian just dropped that as we are using it heavily to plan our releases and sprints. It is a major step back for us!

          1. Shaun Clowes

            Aug 29, 2012

            We would like to revisit release planning in the future, but we're pretty sure it won't be hierarchical versions because they joined the concepts of sprints and releases rather than allowing the two to be related. 

            In any case, we haven't removed any functionality at all, you can continue using the classic boards with the hierarchical verisons if you wish. 

            Thanks,
            Shaun 

            1. Anonymous

              Oct 23, 2012

              Talk about deja-vu. I recall having this conversation with Atlassian 5 years ago. Sprints fit neatly inside releases by definition, always. The notion that we need some mingle style mapping from releases to sprints is over-complicating things for no sensible reason.

              I also recall the conversation about epics from 5 years ago. Epics by definition should not break over release boundaries. On the rare case that they do, it's not a big deal to split 'em. So we should be able to slap epics into releases and have an unscheduled version per release. Plus a button to generate a series of sprints to fit. Isn't this all screamingly obvious? How can a supposedly agile company possibly take this many years to figure it out?

              Just about everyone who needs a tool as complex as GH/JIRA has a group big enough to need to do release planning. If they don't have a group that big, they're much better off using Pivotal or Trello and forget all this stuff. So in ignoring this demand you're preventing almost every large corporation who would like to use GH from using it.

              So ... how to say this delicately ... stop sucking please.

              1. Shaun Clowes

                Oct 24, 2012

                Hi Anonymous, 

                I'm not sure that much of your comment is particularly constructive, but I'd like to reply anyway. 

                I recall having this conversation with Atlassian 5 years ago. Sprints fit neatly inside releases by definition, always. The notion that we need some mingle style mapping from releases to sprints is over-complicating things for no sensible reason.

                Unfortunately that's just not true, or at least not for many GreenHopper users. The ability to split releases from sprints is the third highest voted feature in our public issue tracker ever. Literally hundreds of customers have contacted us to say that their sprints do not fit within releases, many have sprints that work across multiple different projects and so clearly their work does not roll up to a release of one 'product'. 

                For a lot of Scrum teams a release will simply include all of the completed stories that have come out of sprints at the time the release is due to be cut. By putting items in to a release after they have been completed or as they enter in to a starting sprint you can have reasonable certainty they will be delivered. 

                I also recall the conversation about epics from 5 years ago. Epics by definition should not break over release boundaries. On the rare case that they do, it's not a big deal to split 'em. So we should be able to slap epics into releases and have an unscheduled version per release. Plus a button to generate a series of sprints to fit. Isn't this all screamingly obvious? How can a supposedly agile company possibly take this many years to figure it out?

                This also doesn't reflect what our customers have asked us for, the way Epics are used in industry or even how we use them at Atlassian. An Epic can represent a large area of functionality, in Agile spirit we deliver portions of that functionality that deliver value to customers as they are available. For example, in GreenHopper we have an Epic for Epics, it simply wouldn't work to put that Epic in a release because we always release at the end of every two week sprint (i.e. we release stories from the Epic as we go). 

                Just about everyone who needs a tool as complex as GH/JIRA has a group big enough to need to do release planning. If they don't have a group that big, they're much better off using Pivotal or Trello and forget all this stuff. So in ignoring this demand you're preventing almost every large corporation who would like to use GH from using it.

                Actually, you can use hierarchical versions just like you described in the Classic boards, we are not preventing anyone from using it. We're in the process of completely reinventing GreenHopper, we can't do it all at once. So for those that can make use of what we have got today we hope they will, for those who need higher level planning we will deliver that too.

                Thanks,
                Shaun

  2. Anonymous

    Feb 02, 2012

    I've got two issues/questions.

    1. Product releases usually span multiple sprints, but I don't know of any native support in Greenhopper for that concept. We've had to rely on sprint naming conventions and queries, etc. What we really need is a "release" container for sprints that also rolls up all the sprints in the release: features, stats, quality, etc.
    2. Executives and other non-development folks like to visualize release schedules on calendars showing the timeline. In Greenhopper, the time is buried in boxes - a "content priority" view, as opposed to a "time priority" view. So, managers have to resort to things like pulling dates out of Greenhopper and mapping out the releases in Excel or some calendaring tool. All the data is in Jira, though; why not just display it in a calendar?

     

    1. Anonymous

      Feb 14, 2012

      I'll second the #2 issue that you highlighted. Definitely need some sort of visual representation of start/end dates for versions in the Calendar OR some sort of Gantt chart.

    2. Greg Felice

      May 25, 2012

      I agree that this may be an issue - looks like new GH is omitting the release concept entirely in favor of radical (a la Schwaber?) scrum. Is this correct? We've spent a lot of time building up training around a release concept, and it's something quite common with the Scalable Agile Community (Leffingwell). Where is Atlassian going with this? 

  3. Anonymous

    Feb 07, 2012

    what is the current status of this topic? we are just moving from JIRA 4.2 to 4.4 with 2.000 users and I'm struggling with the decision, when and how we should start to move to the Rapid Board. should we wait until old old GreenHopper goes to "classic" mode and you provide us with migration means?

    many thanks and best regards

    Rainer Mueck

    1. Nicholas Muldoon [Atlassian]

      Feb 07, 2012

      Hi Rainer,

      With 2000 users is it safe to say that there are Kanban and Scrum teams? If so, I would encourage you to start by asking one Kanban team to start using the Rapid Board. You can then expand the usage with Kanban teams and also invite Scrum teams to begin using the Rapid Board and providing feedback. 

      At this stage we will be iterating the Scrum for Rapid Board functionality based on feedback. It would be great to start receiving feedback from one of your Scrum teams.

      Thanks Rainer,

      Nicholas

      1. rainer mueck

        Aug 24, 2012

        Hi Nicholas,

        six months later - and I still can't even ask one of our teams to try to use the Rapid Board, because it can't even display one single custom field. we have a custom field called "Feature Rank", which gets inherited from the story's parent Feature (own issue type) and which is THE most important ranking criterion for the stories.

        I'm very sad about this situation.

        Greetings – Rainer

  4. Anonymous

    Feb 09, 2012

    The new GreenHopper will be using a new "Sprint" custom field instead of fixVersion.

    Will you be providing a migration path for old sprints that use fixVersion field to update their issues to use the Sprint field?

    1. iribe

      Mar 28, 2012

      I also interested by the above question: Will the new GreenHopper replace fixVersion by a Sprint field ?

      Thanks for your support.

      1. Shaun Clowes

        Mar 28, 2012

        Hi Jean-Marc, 

        Yes, GreenHopper 5.9.x already includes a new Sprint field that we are using for the Rapid Board for Scrum (which is in labs) instead of fixVersion (the Planning Board continues to use fixVersion). At this stage we don't intend to try to automatically migrate fixVersions to Sprints. 

        Thanks,
        Shaun 

        1. Anonymous

          Aug 18, 2012

          Hi Shaun,

          I like the changes made in GH 6.0. The new feature are extremely usefull and fitting with multiple scrum team using several projects.

          One feature is still missing for building up, display and monitor the aggregation of various sprints team results for planning a release: I mean release planning.

          We are rolling out the full Atlassian solution (jirga, greenhopper, fisheyes, crucible, confluence, bamboo) in the course of the 3 coming months. I am becoming nervous to not have any practical solution for advising the team for release planning.

           

          Can you point me ( even if this not official) on the Atlassian vision or idea for providing such feature ?

           

          Best regards

          Jmi

          1. Ian Brandt

            Aug 18, 2012

            Jean-Marc,

            I asked what I believe is the same question above, though no one has had a chance to answer yet.  See also: GHS-5151 - Getting issue details... STATUS .  If we could get that issue reopened we could direct our votes and comments there.

            All the best,

            Ian

  5. Michael Memeteau

    Feb 13, 2012

    Is the possibility to print agile card from the rapid board also taken into account. For teams that still prefers to have "physical" kanban board, I see this as a must... 

  6. Anonymous

    Feb 14, 2012

    Can WIP Limits be spread across multiple columns ?  Currently this is not available in GreenHopper 5.7.1

    This is essential for Kanban teams.

    1. Shaun Clowes

      Feb 15, 2012

      We understand that this is a useful feature (or could potentially be represented as sub columns of a parent column). This is on the backlog to be addressed in a future release. 

      Thanks,

      Shaun

      1. Anonymous

        Feb 22, 2012

        Thanks Shaun for the reply.

        I couldn't see how to create sub columns.  That sounds like a useful feature.  Is it in versions later than ours (GreenHopper 5.7.1) ?

        1. Shaun Clowes

          Feb 22, 2012

          No, we've not yet implemented this feature and it doesn't look like it will be addressed imminently. You might want to watch the JIRA issue covering it,  GHS-2521 - Getting issue details... STATUS  

          Thanks,

          Shaun

  7. Anonymous

    Feb 15, 2012

    Will a proper mechanism for relating user stories to epics and then managing and reporting on these be implemented in GH6? The kludgey use of labels is not good.

    1. Anonymous

      May 09, 2012

      Any feedback on this? It would really improve backlog overview if a hierarchical view of a backlog with epics user stories and tasks was available. 

  8. Anas Fattahi

    Feb 28, 2012

    I could not find a way to add a card to an existing active sprint. This is a must feature.

     

    Thanks,

     

    1. Anonymous

      Apr 17, 2012

      It's not obvious - on the plan view, drag the card to the "Sprint in Progress" at the top of the list

  9. Ryan Chavez

    Feb 28, 2012

    I am liking where GreenHopper is heading, but I feel like there are a couple of items that I really wish were easier in GH.  In evaluating Pivotal, one of the nicest things is that it just handles a lot of the details for you in terms of planning, forecasting and batch sizing.  It feels as though the planning aspects are being simplified via the scrum templates just added.

    It would be nice to see GH automatically calculate the average velocity based on story points, and forecast based on priority when backlog items will be completed.  I do find that I spend a lot more time trying to forecast and manage that on my own than I would with Pivotal.

    I am excited to try the Rapid Boards which feel like they will solve many of the other problems we've faced with GH (multiple projects support, ease of planning, etc.).

    I would echo another user's comments that better Epic handling would be greatly appreciated, and the ability to report on completion progress for an epic.

  10. Thomas Fettig

    Mar 05, 2012

    Hi,

    I looked at the new Rapid-Board and found it suprisingly responsive. Your software design seems to head in the right direction. Concerning the features i still miss a few things to really make it useful for me (and our scrum-team).

    1. Show Story-Subtasks and make them an object on the rapid board. (How could you ever think to start without it?)
    2. Give total Control about the issues shown on the rapid board. At the moment i see only stories - i want to make the filter rule the board. 
    3. Move Stories into the running sprint, either via 2. (simply manipulate a value to add it) or by a "interactive" Feature. 
    4. Give the issues a field where the Sprint from the rapid board is denoted (could be more than one sprint!). 
    5. a. Make it possible to assign multiple users to an issue. I DON'T want to assign a group, that would be too unflexible. In any agile method communication and cooperation has a central role. Why do you ignore it ?
      b. Alternatively: make it possible to throw out the assigned user from every report (ie. word and xml exports). Better no information than false information.

    As it should, this list is prioritized. Give me 1. to 3. and i could really use it. Give me 4. and 5. and i will praise it (wink)!

    regards

    Tom

     

    1. Shaun Clowes

      Mar 05, 2012

      Hi Thomas, 

      Thanks for your feedback. In the true spirit of Agile we are sharing the Rapid Board for Scrum with customers as we develop it (in labs). As a result many customers are noting missing features that they find important, this is great feedback and we're using it to prioritise what we are working on. 

      Subtasks will be visible on the work mode of the rapid board in the next release.

      The filter does rule the board with some additional restrictions (these are specific to Scrum boards, Kanban has different restrictions)

      • Plan mode will only display issues with a status that is in one of the columns of the work mode (except the last column). It will also not show sub tasks 
      • Work mode will only display issues with sprint in openSprints() and status in one of the columns 

      The ability to add stories to a Sprint will be in the next release (drag and drop the issue in Plan mode on to the active sprint). 

      Thanks,

      Shaun

       

       

      1. Anonymous

        Mar 08, 2012

        Shuan,

         

        do you have an ETA for the next release? We are currently on our 1st month of Jira+Greenhopper testing and having the subtasks in the rapid board is a need before starting to work with it.

        1. Shaun Clowes

          Mar 08, 2012

          GreenHopper is typically released every two weeks (though we're about a week behind at the moment). We should release the next version shortly. 

          1. Anonymous

            Mar 08, 2012

            Thanks a lot Shaun,

            Looking forward to that update!

            1. CG

              May 10, 2012

              As am I. Any ETA on this?

              1. Shaun Clowes

                May 10, 2012

                Hey CG, 

                This went out ages ago! We weren't kidding on the releasing every two weeks. 

                In 5.9.1 (15th of March) we added the ability to see sub tasks on work mode. In 5.9.5 (26th April) we added the ability to quickly add sub tasks in the sub task tab of the detail view. 

                You might want to keep an eye on the JIRA blog where we put out release announcements. 

                Thanks,
                Shaun 

  11. Thomas Fettig

    Mar 06, 2012

    Hello Shaun,

    that sounds great. Can you explain what the position of atlassian is in regards to the two points (4/5) of my list? The impossibility to assign multiple people to an issue is a defect to me (at least if you want to support agile methods).

    regards,

    Tom

     

     

    1. Shaun Clowes

      Mar 06, 2012

      Unfortunately the fact that only one assignee is possible is a JIRA restriction (not GreenHopper). The issue has been commented on many times at the JIRA public issue tracker, there are a variety of workarounds but there's little that GreenHopper can do here. 

      Thanks,

      Shaun

  12. JIRA Autobot

    Mar 09, 2012

    Any plans to see the total story points on a epic ? Right now an Epic shows - and only the stories pointed to that Epic shows the story points. It would be useful to see the total story points on an epic on the rapid board.

    1. Shaun Clowes

      Mar 11, 2012

      Hi Donnib, 

      The story points for an Epic are just like the story points for a story, you can click on the story point value (in this case the '-' indicates empty) and fill in a value. 

      Thanks,
      Shaun 

      1. Anonymous

        Mar 12, 2012

        Shaun Clowes you might have understood my question or i might not have explained it thoroughly. What i want it so see the total story points on the epic from all the stories that refer to it. For example i have two stories with each 5 points that refer to the Epic. I would then like to see 10 points in total on the epic.

        Hope this makes more sense.

        1. Shaun Clowes

          Mar 12, 2012

          OK, I understand now. We're not likely to implement this soon because many Agile practitioners follow a different approach where the Epic is estimated independently (e.g. at 200 story points) and then break down that Epic in to smaller stories over the course of the project or several releases. This means that the Epic will usually have a higher estimate than any stories that are connected with it (or at least needs a way to override the sum of the sub story points). 

          We do plan on cleaning up Epic management in the future so we may come up with an alternative approach to Epic estimate management. 

          1. Jason Brison

            Jul 06, 2012

            Hi Shaun Clowes,

            I have a few question re: epics and GH: RB

            1. When will Epics work properly in the Rapid Board like they did in the classic?
            2. When will we be seeing some better Epic management?

            We have a lot of people who are looking to switch from Rally to GreenHopper for their Scrum / Kanban management, but without proper epic management in the Rapid Board users are refusing to make the move.

            A rough ETA (next release, few months, next year, etc) would be great if it's possible.

            Thanks,

            Jason

            1. Shaun Clowes

              Jul 07, 2012

              Hi Jason,

              We don't generally share roadmap information or timeframes because we try to respond to change and as a result our plans are fluid. 

              I'm not sure that Epics will ever work in the Rapid Board like they do in Classic (I'm not saying that categorically, just that I suspect it's unlikely). We plan to reimagine Epics from the ground up when we implement them in the Rapid Board and will most likely use system issue links as opposed to the current label approach. 

              If you'd like to share some screenshots of how you use Epics in Rally and your key use cases we'd be happy to consider them as we move forward. If you'd prefer to email my address is "s clowes at atlassian dot com" (ignore spaces etc).

              Regarding time frames, as above I can't really offer much there. I can say that Epic management is the second item on our major feature backlog (multi sprint planning is the first). Given that we release roughly every two weeks or so, you could interpret some rough timeframes from there, definitely less than a year obviously. 

              Thanks,
              Shaun 

              1. Edwin Stol

                Jul 09, 2012

                Hi Shaun,

                Good to hear that the Epic management is of a high priority. The problems that we encounter is that it is currently impossible to create a burndown based on a Epic/Theme level. I hope you take this into account as well when you guys start building on Epic management.

                Thanks,


                Edwin

                1. JIRA Autobot

                  Jul 09, 2012

                  Edwin Stol, i am curios, why do you want to see Epic/Theme burndown chart ? Are you actually using Epic/Theme and following those issues ? If so why are you not using stories ? I was convinced that Epic are placeholders for tasks that need to be split up in many User Stories.

                  /donnib

                  1. Edwin Stol

                    Jul 09, 2012

                    We use a seperate field named 'Theme' to label/categorize cross-project user stories.

                    i.e give me everything that relates to 'API' across the projects Greenhopper, JIRA and Confluence. Our project managers want a burndown on the 'Theme' level as well.

                    The Epics are placeholder stories indeed, so i do not need a burndown on that level.

                    1. JIRA Autobot

                      Jul 09, 2012

                      Yes i understand, with Rapid Board i think you could get that overview since Rapid Board is can be used cross project. So let's say that you create an rapid board that has project A, B and C. Then you start a sprint doing all sort of things. You can then follow your Sprint burndown chart for that Sprint but across project A, B and C. Would that fulfill your requirement ?

                      1. Edwin Stol

                        Jul 09, 2012

                        No, that would not.

                        I've looked into this option as well, to create a rapid board based on the theme 'API' for instance and all of the projects that i have. That would give me a massive backlog, and i could put all the issues in one sprint with a long-term period to have an overview of what is resolved and what not.

                        Problem is is that i cannot plan these issues into an actual sprint for a team.(we use Rapid Boards to create virtual team backlogs as well).

                        I've looked into your other replies here as well, and i think your architecture is a little different from ours.

                        Anyway, an Agile Gadget that would be able to do a burndown based on a custom filter that doesn't require a fixversion for all the issues would be fine as well.

                         

              2. rainer mueck

                Jul 09, 2012

                Hi Shawn

                you wrote: "I'm not sure that Epics will ever work in the Rapid Board like they do in Classic".

                That is good news to me. We had introduced the Epic quite a while ago but the teams used it either wrongly or most of them not at all. The reason for this is clearly the way it is implemented in GreenHopper. We removed the Epic again - sad but true.

                I think the root problem we all suffer is the missing "Ability to define a Issue Hierarchy" in JIRA (JRA-4446, JRA-15169). Having this ability would enable us to model the whole picture like

                    Theme -> Feature -> Epic -> User Story -> Story Task

                with aggregation of standard- and custom fields on each level ... just great!

                are there others sharing this dream?

                kind regards – rainer mueck

                1. Jeff Patterson

                  Jul 25, 2012

                  Absolutely share that dream... lack of an arbitrarily hierarchy in JIRA is a huge shortcoming for us.  We use (and love) the Structure plug-in to help organize the Backlog, but its data & organization is somewhat disconnected from the rest of JIRA.  You really need to have some way to relate stories in the Backlog to larger-grained things, and for now we're a little stuck... though I've heard that Structure has plans to provide a tabbed "where am I in Structure" panel in the Rapid Board sometime soon.

                  BTW you can support that Structure enhancement by voting for http://jira.atlassian.com/browse/GHS-5517 

                   

                2. Anas Fattahi

                  Jul 26, 2012

                  @rainer I agree 100% with you. The key  is to support aggregation of nemuric standard and custom fields at least for the epic and stories with sub tasks

                3. Martin Geck

                  Aug 24, 2012

                  You may want to vote for  GHS-2136 - Getting issue details... STATUS  

  13. Anonymous

    Mar 20, 2012

    What if I need to manage multiple project  that require different Column headings?  - There isn't a way to have multiple rapid boards each with their own Column layout as there is with the task board. 

    If there is please send me a link where I can find out more 

     

    1. Nicholas Muldoon [Atlassian]

      Aug 12, 2012

      Hello,

      You can configure multiple boards, each with its own configuration - project, column, swimlane, etc.

      See Using the Rapid Board and Configuring a Rapid Board for more details.

      Thanks,

      Nicholas Muldoon

  14. Jeremy Neuharth

    May 08, 2012

    The one thing our teams are now using is the concept of iterations within a sprint. In other words we will have a sprint planning session for a month long sprint. Then we will have weekly iteration planning meetings (much smaller) in which the team breaks up their work a bit more in order to feel comfortable with reaching the larger sprint goal. Will there be a concept of "nested" items within the new Scrum features of Greenhopper? If not I think we could work around it with having multiple sprints, but just wanted to know the direction. I believe that there are quite a few Scrum teams doing a similar thing, although I am not sure how popular doing something with the sprint/iteration relationship really is.

    What is nice about nested versions today is we can have burn downs for the overall sprints, as well as for the iterations. With that said, we are very happy with the separation of versions from sprints!  It has been helpful for the individuals outside the Scrum team to focus on a "release" version rather then all the sprints/iterations mixed it.  Wouldn't think that it would be that big of deal, but I guess it is for them.

    Respectfully,

    Jeremy Neuharth

  15. JIRA Autobot

    May 22, 2012

    Here are some things i miss on the SCRUM Rapid board :

    1. An view of all Sprints that belong to a version (there is no coupling for this now), it does not have to be coupled to fixVersion but i want to see an burndown chart in storypoints for all sprints at the same time so i can see how the Release is progressing each Sprint. Here is what i want to see :
    2. An possibility to Estimate my Stories in Story Points but estimate my Technical-subtasks in Ideal Time (Original Estimate), as it is now i can only use stimate either on Original Estimate or Story Points but i need to estimate differently depending what kind of issue. This leads me to this one : 

      I know that above graph can be seen today but as i said i need two different burndown charts, one in Story Points for the release and one in Ideal Time for each Sprint.

      /donnib


    1. iribe

      Aug 18, 2012

      Hi donnib,

      I support your request at 100%. Your points are correct, we need also 2 burndown charts for Sprint purpose in remainingn efforts and one for the release planning purpose in story points.

      I will be very interested to get the feedback from Atlassian (smile)

      Bets regards

      JMi

    2. Edwin Stol

      Aug 30, 2012

      I'm looking for 1 for a while now too; my managers are starting to lose confidence in this getting solved, and are suggesting we look for other possibilities.
      Until now, i've been able to keep this off, because this is actually one of the only thing we really need and miss.

      Still, i'd be nice if Atlassian would extend the Agile Gadget to support creating charts without the need for filled in fixversions.

       

  16. Anonymous

    May 23, 2012

    Any ideas on when we will see some of the new features in JIRA 4.  Our organization just updated to JIRA 4 (we are behind the times), but I would like to use some of the features I am seeing in 5.9.5.

     

    Currently, we cannot upgrade past 5.8.7

    1. Nicholas Muldoon [Atlassian]

      May 23, 2012

      Hello,

      Great to hear you are eager to use some of the new features we've recently released.

      GreenHopper 5.9.x relies upon functionality introduced in JIRA 5.0. This means that we are unable to provide the new functionality for JIRA 4.4.x or earlier.

      Please use our support team for assistance in upgrading at your earliest convenience.

      Thanks,

      Nicholas Muldoon

      1. Anonymous

        May 24, 2012

        Thanks for the reply!

         

        So, are you planning on supporting JIRA 4.4 with Greenhopper 6?  Or are we "stuck" with 5.8.7 (sad)

         

        We would love to be able to better utilize the Rapid Boards and have the feature of separating the Sprint from the Fix Version.

        1. Nicholas Muldoon [Atlassian]

          May 24, 2012

          No, GreenHopper 6 will not be JIRA 4.4 compatible. You're not stuck though, simply Upgrade JIRA. 

           

          Thanks,
          Nicholas 

          1. Anonymous

            Jul 19, 2012

            Thanks again for the reply.  Is there any way we can just get the feature in JIRA 4.4 / Greenhopper 5.8.7 to separate out Sprints from Versions?  Pretty please?  I don't need anything else, just that.

            I would love to go JIRA 5, but since we JUST went live, and we are a BIG development org, it is proving a difficult sell at this time to upgrade.

            1. Shaun Clowes

              Jul 22, 2012

              Unfortunately it wouldn't be useful even if we did. The Planning/Task/Chart/Released boards continue to use fixVersions for Sprints, it's only the new Rapid Board that uses the new Sprint field. Because the Rapid Board has had many many features added since 5.8.7 it's impossible for us to back port them. 

              Could you potentially use a separate JIRA 5 instance (maybe even in Atlassian OnDemand) for your project? 

              Regards,
              Shaun 

              1. Anonymous

                Jul 22, 2012

                Unfortunately, we cannot use a separate JIRA instance, at least not right now.  I'll push for an upgrade, guess we'll have to fight through it.

  17. Anonymous

    Jun 08, 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

    1. Edwin Stol

      Jun 11, 2012

      I second this motion (smile)

    2. Tom van Heiß

      Nov 12, 2012

      Same opinion here... my PO would really enjoy some more information (columns) on the planning board, for example components.

      The board lines (means issues) should be configurable. Without these additional fields you always tend to put these information in the issue title (that's redundant and they definitely do not belong there)!

      That's a very important feature for us to control our product backlog!

      By the way: just saw the new epic bubble in the plan board with the (labs) epic feature from GH 6.0.6. Having epic information there is good, but the implementation doesn't look very nice and is not hierarchical, an important aspect of using epics.

    3. rainer mueck

      Nov 12, 2012

      I'm terribly missing my custom fields that are key input criteria for manual issue ranking. Keeps me from using the new board.

  18. Jason van Beukering

    Jun 11, 2012

    When can we expect the ability to run multiple simultaneous sprints?

    1. Shaun Clowes

      Jun 11, 2012

      You can do this today, a Rapid Board can have multiple Sprints on it at once (the Sprints are picked up by looking at the Sprint field for all of the issues in the board). You cannot plan another Sprint on a Rapid Board where there is already an active Sprint attached to the issues.  If you just make sure that your Rapid Boards select separate sets of issues you can use them totally independently. 

      The ability to plan multiple Sprints in advance is something we intend to address soon. 

      1. Edwin Stol

        Jun 11, 2012

        Shaun,

        In advance on the ability to plan multple sprint, we use milestones to define our future sprints. (i've outlined our method here: Re: Starting a Sprint). That works quite nice, apart from the fact that the milestone should have a contrasting colour (so they stand out). If you could make that possible on a short term, it would be good enough for us for now.

        Regards,

        Edwin

      2. iribe

        Jun 22, 2012

        Hello,

        This request (planning several Sprints upfront) is deeply linked to the capability to  support the Release planning exercice. Sorry for being black and white, but we will not use the rapid board until the concept of Release will not be supported. In Software development the concept of "Release" (aggregate the result of several Sprints to deliver Marketable value) is essential.

        I would be happy to contribute if possible, any advice to me to this contribution: forum, sandbox....

         

        Best regards.

        JMi

  19. Torsten Allard

    Jun 20, 2012

    Three questions regarding Rapid Board:

    • When can we set non-working days for the burndown chart?
    • When can we flag impediments with yellow exclamation marks (or something similar)?
    • When can we customize issue type colors (as it would help colorblind people a lot)?

    1. Shaun Clowes

      Jun 20, 2012

      Hi Torsten, 

      These have all been requested in our public issue tracker so you might like to express your support by voting on them: 

      GHS-2526 - Getting issue details... STATUS  

      GHS-5117 - Getting issue details... STATUS  

      GHS-1261 - Getting issue details... STATUS

      Thanks,
      Shaun 

  20. Anonymous

    Jun 26, 2012

    Hello,

    Since moving off of Rally to Greenhopper, our Scrum teams have been asking for a way to do capacity planning of individual team members for a sprint, prior to sprint planning.  Anything in the works for that?

    Thank you.

    Felicia

     

     

     

    1. Anonymous

      Jul 31, 2012

      Try using Team Calendars

  21. Jeremy Neuharth

    Jun 29, 2012

    Is there plans to open up the Rapid Board to allow plugin development?  For example we would love to create a plug-in that would allow us to add a tab in the detailed view with some custom fields we use a lot in our installs.  We would also like to build another plugin that would allow us to incorporate our estimation process right into Greenhopper.  We know the rest API is there, but we really want to build right into the UI to keep it easy and fast for our teams.  Right now they are starting to live in the Rapid Board's work or plan mode and we would like to take advantage of that. 

    Respectfully,

    Jeremy Neuharth

    Founder | Sycorr

     

  22. Simon Davison

    Jul 19, 2012

    Are there any plans to allow Confluence to view any of the Agile charts? All of my project related status information along with feature details etc is in Confluence, but actual progress on delivering those features is trapped within Jira. The ability to provide a one-stop overview of a release/sprint to my Exec team without needing to link to JIRA would be a significant product improvement for Greenhopper.

    1. Jason Brison

      Jul 20, 2012

      You can add the dashboard gadgets from JIRA to Confluence and then display them on wiki pages. Here is a link which explains Add JIRA Gadgets to a Confluence Page.

  23. Laszlo Kremer

    Jul 27, 2012

    We decided not to switch to the new scrum board because of the lack of key scrum features  - which exist in classic mode. Without correct release planning, epic handling, impediment flagging, at least two configurable field on cards etc. in the new scrum feature, we cant switch. These are essential to scrum (and currently working fine in classic boards!).

     

    Yes, the new scrum board has killer new features (eg.: retrospective) which we really like, and we would like to start using them, but I still feel, that it should have the Labs tag on it, as it is only partially usable. 

     

    I really hope, that classic boards won't get fired from GH before new boards get these functionality, because we'll stuck at the current version.

    1. rainer mueck

      Jul 30, 2012

      Thank you Laszlo - I strongly second this post!

      See also comments of mine for  GHS-3922 - Getting issue details... STATUS

       

    2. Anonymous

      Jul 31, 2012

      I'm pretty sure there is no mention of Epics, Flags or configurable fields anywhere in the scrum guide, how are they essential to scrum?

      1. Laszlo Kremer

        Jul 31, 2012

        Yes, and there is also no mention of a scrum support tool (smile) Indeed, I ought to change the word "essential" to "extremely useful", and the picture would be nicer.

         

        But please keep in mind, that when people see words like "available...until.." related to features they rely on: can be confusing.

      2. iribe

        Jul 31, 2012

        hello,

        I also support this point. We close to have a large deployment of GreenHopper, and even if the Rapid Board is solving the problem of the Cross project work items, some important missing features will prevent us to use it: ReleasePlanning (distribution of UserStory over Sprints, and estimation of the number of Sprints required for a Release), Display of custom fields in the RapidBoard.

         

        So I hope and strongly recommend to keep the previous (Planning Board using Versions) available until the similar features will be supported by the RapidBoard.

         

        JMi

         

  24. Anonymous

    Jul 27, 2012

    Unfortunately, there is no way to start sprint in Rapid Board with date from the past. So if I forget to start a sprint in Greenhopper in an appropriate day (we mostly work offline with paper user stories), I'm unable to synchronize it later with Greenhopper.

    1. Shaun Clowes

      Jul 29, 2012

      Obviously, we'd hope that you start your sprint in GreenHopper at the same time as you physically start it. After all, it is our goal to be so effective that you want to use us instead of your paper user stories. 

      However, you can do what you're looking for. Once you have started the sprint you can edit the start date from the sprint summary box at the top of Plan mode. 

      Thanks,
      Shaun 

  25. Anonymous

    Aug 06, 2012

    Is there a way to use the "fix version" as swim lanes on the rapid board - this would be very useful to sort stories on the rapid board. 

    It would alos be great if the fix version could be edited on the detail pane of the rapid board too.

    Thanks

    1. Shaun Clowes

      Aug 07, 2012

      There's no automatic way to do this but you can configure fixversion based swimlanes in JQL in the Rapid Board configuration screens. 

      Thanks,
      Shaun 

  26. Anonymous

    Aug 13, 2012

    Is it possible to migrate/move/convert completed and released sprints from classic to the new board? Because with the new board the velocity chart starts empty.

    1. Shaun Clowes

      Aug 13, 2012

      No, there is no way to migrate the fix versions as Sprints to the new board. We recommend referring to the Classic Chart Board to determine velocity while you are building up velocity information in the new board. 

      Thanks,
      Shaun 

  27. Anonymous

    Aug 19, 2012

    GreenHopper team,

    first of all:

    thanks to all of you that you provide increments and (thumbs up) (plus)(plus)product enhancements (plus)(plus)(thumbs up) on a (nearly) monthly bases (thumbs up)

    I prefer this method (every month a new surprise) instead of having two big bangs a year.

    Nevertheless, we lost one vital "dimension" with the new board (compared to classic mode): the big picutre.

    I created an feature request, so please join the discussion here: GHS-5667.


    AM

     

  28. Axel Heindrichs

    Aug 29, 2012

    Hi,

    we like the new board very much. It's definitely an improvement over the classic board. However I have an issue with the new boards concerning the use or not use of the fix version.

    It's great that you have uncoupled the fix version from the sprint but now I miss the fix version in the new boards.

    I regard the fix version as a way for release planning and I think that's also as it was intended. However how do I get a clear overview of all the issues that are planned for the upcoming release(s). This was very valuable in the Classic boards.

    Cheers.

    1. rainer mueck

      Aug 29, 2012

      I'm having the same question ...

    2. Shaun Clowes

      Aug 29, 2012

      We'd like to look more at release planning in the future.

      For now I'd suggest using quickfilters (for example "fixVersion = empty" will show you issues that aren't scheduled for a release, or "fixVersion != empty" will show you scheduled issues). 

      You can mark all issues for a release based on a sprint by using the sprint report, clicking the 'View in Issue Navigator' link then using bulk edit. 

      Thanks,
      Shaun 

      1. MattS

        Oct 22, 2012

        Yeah, that's what I do. All that's missing is a way to total the estimates for multiple sprints and an epic.

    3. Max Seelemann

      Aug 30, 2012

      We use regular issue filters and the quick filters Shaun mentioned for that.

  29. Anonymous

    Sept 26, 2012

    I am currently on JIRA 4.4 and GH v5.8.4 and our team is looking to upgrade to the latest version.  I have not played with the 6.x features in GreenHopper, but I have some concerns.  I am using JIRA to manage technical product development tasks (deploying hardware, writing training documentation, etc).  I have been using fixedVersion to align with Stage Gate Projects which are planned releases.  I am concerned the new functionality of sprint PLAN / WORK mode will take away current functionality from my user community.  These are my questions:

    1. Can I still have multiple different FixedVersions?
    2. Can I easily drag and drop stories from unscheduled to FixedVersions?

    Thank you in advance for your assistacne. 

  30. Anonymous

    Nov 09, 2012

    This new board goes in the right direction, however, to all greenhopper users : think carefully before migrate your classic boards to the rapid boards, some importants features are still missing :

    • There are no gadgets that tie to the rapid board: no hour burndown chart, no cumulative flow chart...
    • If you are using a physical board, you can't print yours cards
    • The non working days are ignored by the burndown chart
    • There is no easy way to search issues for a sprint

    1. Laszlo Kremer

      Nov 10, 2012
      Kanban teams definitely benefit from the new boards, Scrum teams will like the new approach but definitely miss a bunch of features from the Classics.
      • No easily accessible Impediment flagging 
      • Release planning has to be done on the Classic Boards
      • Burndown chart does not shows trend
      Searching: I don't think I get it. The new planning board's instant filter kicks ass.

      Big good point is that it is evolving very fast.

    2. Wojciech Seliga

      Nov 11, 2012

      If you are using a physical board, you can't print yours cards

      This one at least is addressed by a dedicated plugin - Agile Cards for JIRA - which does it much better than GreenHopper ever did. And it fully integrates with GreenHopper new boards.

       

  31. Doug Pitters

    Nov 10, 2012

    Hi,

    We've just been experimenting with the Rapid Boards with one scrum team, and it seems to work well enough to use (GH 6.0.2). 

    Yet in order to go from one or two teams (with a board each), to 15 teams, I need to be able to scale rapid board creation, mostly through automation.

    Are there any recommendations on how to set up rapid boards in bulk?  Adding unique sprints for multiple teams in bulk?  In the classic mode, sprints are just fixVersions, so we can use JIRA's rest and other remote api and map them more or less cleanly to the agile classic boards.  But with the new sprint fields there doesn't seem to be anyway to create or access them outside the actual plan mode.

    Any ideas?

  32. Hans-Hermann Hunfeld

    Dec 03, 2012

    Is there any option to create hierachy between version which is not settled in the classic boards? AFAIR this can only be done there, can´t be?

  33. rainer mueck

    Dec 03, 2012

    You may want to vote for and/or comment on GHS-6754 - Getting issue details... STATUS (As an Atlassian (enterprise) customer I request that Rapid Board fulfills some MUST HAVE requirements).

     

  34. Anonymous

    Dec 04, 2012

    Is there any plan on getting Epics to work "properly" in KanBan boards?

    1. Nicholas Muldoon [Atlassian]

      Dec 16, 2012

      Hello,

      The Epics are not presently available in the Kanban boards as we have yet to implement the Plan mode. For more on this please keep an eye on  GHS-6175 - Getting issue details... STATUS .

      Thank you,
      Nicholas Muldoon
      @GreenHopperTeam 

  35. Laszlo Kremer

    Dec 11, 2012

    It is kinda disappointing how Atlassian handles this Classic-Rapid board transition. We are literally pushed to the Rapid boards as Classic boards are abandoned. 

    Personally I would not recommend anyone start using GreenHopper above medium-size software development companies. Classic boards used to be a great product with outstanding features, Rapid board probably will be a great product with other nice features. We are in-between. Classic is supported somehow, Rapid came out from Labs too early.

    This makes a customer lose trust in Atlassian rather than the current product. What's with Fisheye, Crucible etc.? Will they make turnarounds right after we purchase that product?

     

    1. Shaun Clowes

      Dec 12, 2012

      Hi Laszlo, 

      As the old saying goes, the journey of a thousand miles begins with a single step. The new boards are quite functional now but we're continuing to build them out until they will eclipse the functionality of the Classic Boards.

      In the interim however, we understand that some users, particularly larger companies, need some of the more advanced functionality that is present in the Classic boards that will take us some time to build that in to the new boards. We continue to provide the Classic boards for exactly this reason. You can continue to use the Classic boards if they meet your needs while we continue to build out the new boards.

      We introduced the message that states 'The Classic boards are no longer being actively improved and are not recommended for use in new projects' to make it clear to users that do not read pages like this one that the new boards represent the future of GreenHopper and to get people to consider migration. Many users have already switched, which is great, but we recognize that the only way to get everyone to switch is to deliver the features they need and we're working as fast as we can to do so.  We are closely monitoring the usage of the old boards vs the new boards and we do not intend to end of life the classic boards until the vast majority of users have migrated. 

      We really had to break away from the Classic Boards in order to deliver functionality customers have demanded for years such as personalized boards, multi project support, swimlanes etc etc. We plan to continue delivering great improvements every two weeks. 

      Please continue using the Classic Boards if you prefer, it's our job (and our intention) to win you over to the new boards by delivering the features you need. 

      Thanks,
      Shaun

      1. Laszlo Kremer

        Apr 24, 2013

        Hi Shaun,

         

        With the current release we are considering switching some of the scrum teams to the new board. The new release planning feature is a huge leap forward. You are just starting win us over the new boards.

         

        Keep up the good work!

        1. Tom Kotecki

          Apr 29, 2013

          Hi Laszlo,

          Thanks for your kind words, that's great to hear (smile) Looking forward to hearing your feedback after those teams make the switch!

          Cheers

          Tom Kotecki

          Product Manager, GreenHopper

          1. Laszlo Kremer

            Jul 23, 2013

            Hi Tom,

            After 3 months I think I can provide some feedback.

            The release planning feature was a huge push to change the teams to the new boards, and the second was the info, that the classic will be discontinued. So we are just scheduling the remaining teams for switch.

             

            The good: the relief, that fixversions can be really fixversions. Before that, this field was spoiled by the epic and sprint infos.

            The bad: we still lack of features, that the classic board had:

            • issue burndown chart (I can't stress enough how importand this is), with trendline and wallboard gadget. The current story point burndown is not very usable if you have stories which are somehow connected, and can only demo them at the end of sprint. The chart is a flatline and breaks down at the end, while the tasks are burnt nicely.
            • version report could have issue-subtask hierarchy + configurable fields. Issue navigator is not a solution for that, because only the report shows the story point statistics. A separate quickfilter list would be awesome here. Release managers rather use the classic interface.
            • Work mode overview: having a medium sized team, they'll work with 8-10 stories, each have 5–8 tasks. You end up scrolling continuously. The cards are too big. Knowing that the cards will not be configurable, a more compressed view would be awesome.
            • Inline edit on detail view - "the classic had it, why would we change?" - I can't really answer to this when I'm asked. And they are right.

            This is only four things among many other, and I'm sure that you are aware of each, but we don't know whether these got addressed in the foreseeable future. I know that you can't show the roadmap, but knowing the directions would show the light.

  36. Anonymous

    Dec 12, 2012

    @Laszlo Kremer: You are a man of my own heart. I feel totally the same way. It is pretty obvious where Atlassian is moving: "make our products easier to use". This esentially means that their USP, being configurable, tailorable and customizable, will go away eventually because they feel that both do not go together very well. You should take this into account for your future of using Atlassians' products.

  37. rainer mueck

    Dec 12, 2012

    Thank you Laszlo - once again I strongly second your post!

    We tried to convice Atlassian to change their mind ( GHS-6754 - Getting issue details... STATUS ) - no success.

  38. George Cusumano

    Jan 04, 2013

    Capacity hourly rollup missing? Our team generally estimates in Story points and Sub-tasks out in hours. At the end of the Sprint planning, we check hours to ensure our developers did not over commit (ie. Developers are given 30 hours of work in a sprint). Our former Agile tool (Rally) would have a “Team status” where we could set a hour capacity for individual developers and a Scrum Master could see how many hours they had committed in Stories and Sub-Tasks toward their total hourly capacity. The only way I can see to view hours for individuals is to count the hours on each card on the Work board and manually sum them up. Is this something that Atlassian plans to address in future GH releases?

     

    1. Rosie Jameson [Atlassian]

      Jan 06, 2013

      Hi, you may like to vote/watch/comment on GHS-1333 - Getting issue details... STATUS

  39. Jeff Patterson

    Jan 14, 2013

    Our team's making good use of the new Boards and Epics, but a couple of things continue to confuse and frustrate people:

     - the mysterious parallel Epic/child relationships - the old one using the Epic/Theme field, the new one using drag & drop in the Plan view - is very confusing to those of us who had previously used Epics.  People still edit Epics membership "the old way" and expect those Epic/child relationships to be reflected in the Plan view.  There shouldn't be any important relationship that can only be created/managed via drag & drop.

     - the numerical-only editing of Sprint fields (vs. by Sprint name) in the Issue Navigator/edit view is really poor - when someone edits the Sprint field, which people do, they should see a list of Sprints by name rather than a raw list of index numbers.  People inadvertently make all sorts of mistakes as s result, and wonder why their issue ended up in the wrong Sprint.

    Thanks!

      jeff

    1. Rosie Jameson [Atlassian]

      Jan 14, 2013

      Re: editing of Sprint name – you may like to watch/vote/comment on GHS-6459 - Getting issue details... STATUS

  40. Anonymous

    Jan 17, 2013

    In the Rapid Board for Scrum when using Swimlanes by Story is there anyway to include the parent ticket on the board as a card that can be moved through the defined states (currently it seems to be fixed and spans all columns)?

    Our current parent tickets have their own workflow which we need to transition through which is different to the subtask workflow. We currently show all workflow states on a single board because the workflows are similar but the parent task has extra states.

    We can achieve the goal by using the Swimlane by Query and setting queries for each parent ticket and child tasks but this has two problems.  One is that it is unnecessary effort at the beginning of each sprint to set up and the second is that it wastes screen space by including the parent "header" above each subtask card.

     

    1. Tom Kotecki

      Apr 26, 2013

      Hi

      The only way to achieve this at the moment is via custom swimlanes like you said, or - since you're worried about screen real estate - not using swimlanes at all (which should give you the most compact view with both stories and subtasks as their own cards).

      Regards

      Tom Kotecki

  41. Anonymous

    Jan 18, 2013

    Is it possible to report multiple parallel sprints onto a single burn down chart?  I'd find that a useful feature. 

    1. Edwin Stol

      Jan 21, 2013

      I'd rather see a (generic) burndown chart that supports a JQL query and a time period. You can then report on sprints, or releases, or whatever you want.

      1. Laszlo Kremer

        Jan 24, 2013

        +1 That would solve a bunch of feature requests.

  42. Jeff Patterson

    Jan 22, 2013

    The new Epics are great - one minor usability enhancement our folks are asking for is to automatically pre-fill/echo the Epic Name with the first x-many letters of the Epic issue Summary, so people don't always having to type in the same/similar thing twice.

  43. Anas Fattahi

    Feb 05, 2013

    When are you going to open the latest features to the Kanban board, like the planning board, epics management, bulk updates, etc... they are way overdue

  44. Paul Cleary

    Mar 05, 2013

    I am looking into switching from Version One to Greenhopper.  I like alot of things about JIRA in general, and even greenhopper, but it seems to be lacking the kind of "top-down" organization and rollups I get with Version One.  I can kind of do some of the organization in the Classic boards.  Is there a plan to introduce that kind of top-down / rollup view in Greenhopper, perhaps the next version of the Classic boards?

    To clarify on "top-down", I can easily do Product Planning, Release Planning, and view status by Product, Release, or Program in VersionOne.

    1. Tom Kotecki

      Mar 08, 2013

      Hi Paul,

      We do not plan on releasing further features to the Classic Boards - all our efforts are 100% on improving the new boards as fast as possible. Incidentally, one of such improvements is Release Planning (the first version of which you can see in Labs in 6.1.4), and we plan on improving it rapidly in the upcoming releases. This, combined with current functionality such as Epics, should allow you to do Product and Release Planning.

      Regards

      Tom Kotecki

      Product Manager, GreenHopper

  45. Laszlo Kremer

    Mar 06, 2013

    +1 to the Kanban planning and epics approach.

    There are kanban teams who actually do scrumban, they do have some planning, they do have epics, but their main job is done as kanban work (think about IT teams). They don't necessarily work in iterations, so they don't really need sprints, the kanban board's release feature is quite ok. These scrumban teams also could utilize the benefits of the new epic approach.

     

    Opinions?

  46. Tom Kotecki

    Mar 08, 2013

    Hi Laszlo,

    We can see the need for this, and are likely to look at it when we revisit Kanban functionality in the future. Unfortunately I can't provide any more accurate estimate than that at this point.

    I would recommend watching  GHS-7052 - Getting issue details... STATUS  to stay up-to-date on Epics in Kanban, and GHS-6175 - Getting issue details... STATUS  for Kanban Planning.

    Cheers

    Tom Kotecki

    Product Manager, GreenHopper

  47. John Meyer

    Apr 10, 2013

    Is it possible to get a product backlog report that is organized by epic and/or rank?  It is difficult process preparing the business for a discussion.  Please advise, thanks. 

    1. Rosie Jameson [Atlassian]

      Apr 12, 2013

      We currently have a report for individual epics (please see Viewing the Epic Report). For a report on all epics, you may like to vote/watch/comment on GHS-6391 - Getting issue details... STATUS

      1. John Meyer

        Apr 12, 2013

        Thanks Rosie. What I am looking for is a report or an excel export that contains a detail list of all the open issues in the system (summary/description) with the name of the epic on each line, so that the product owner can see the entire option space in one document.  Currently the systems only show the ticket number of the epic, which requires gyrations in excel to create a useable report. We need this every week, it's the most important report we run.  This seems like a simple, customer-facing request but it is not actually available in either of the reports you mention.  Makes it challenging to prove the value of JIRA /Greenhopper if this "product backlog" report, which is in chapter one of Ken Schwaber's books on Agile, is not easy to run.  Product owners are typically not interested in burndown charts or web based interfaces, as they typically have to circulate the info with larger non technical audience on the business side.

        1. Tom Kotecki

          May 16, 2013

          Hey John,

          If what you're after is the list of all open issues with the name of epic on each line, then it looks like the plan mode has everything you need. Is your main concern that it's web-based?

          We also plan to implement an all-epics report ( GHS-6391 - Getting issue details... STATUS ), as well as expose full epic name during excel export ( GHS-8833 - Getting issue details... STATUS ), so if any of these are what you're after, you can watch them to be updated on any progress.

          Cheers

          Tom Kotecki

          Product Manager, GreenHopper

  48. user-fc493

    Apr 15, 2013

    I'm trying to find out the sql for the velocity chart.  I got most of it figured out, but cannot figure out the commitment versus completed part.  

  49. Paul Cleary

    Apr 23, 2013

    Are there any plans to have a version workload report for Sprints?  Right now, I have to create a "Sprint Version" by hand, and assign the same stories to the Sprint version, so that I can see a version workload report.  It would be nice if this was a standard report on the Report tab.

    Yes, I know that in pure Scrum, you don't assign tasks up front, but I use it as a way to understand dependencies on skillsets during sprint planning.  It would be very helpful to see this kind of report in the Rapid board.

    1. Rosie Jameson [Atlassian]

      Apr 28, 2013

      You may like to watch/vote/comment on GHS-5849 - Getting issue details... STATUS

  50. Dave John

    May 14, 2013

    The new boards seem to be custom for each team.  I liked the ability to create a custom board template in the old version that would apply to all projects.  For instance, we have 5 columns instead of three for the "task board."  Will that be re-instituted?  It helps ensure that our entire organization is using Greenhopper and Agile consistently so if they change teams, at least that remains constant.

    1. Rosie Jameson [Atlassian]

      May 15, 2013

      You may like to watch/vote/comment on this issue: https://jira.atlassian.com/browse/GHS-6790

      In the meantime, perhaps using "Copy" when you create a new board may help a little.

      1. MattS

        May 15, 2013

        Rosie, you know there's something I haven't seen documented about that. When you copy a board it uses the same underlying saved query I think. Changing the query in one board changes it for the copy as well. But it's not clear how to stop using the shared query, if even possible.

        1. Rosie Jameson [Atlassian]

          May 15, 2013

          Hm, sounds like that documentation is too well hidden (smile)

          Maybe I should put "Copying a Board" on its own page to make it easier to find?

          Creating a Board#CopyinganExistingBoard

          1. MattS

            May 15, 2013

            No, I think I just missed that bit (smile) However this bit is confusing: "You will be the owner of the new board, but not necessarily of the filter." And the linked page at Configuring Filters tells me how to edit a filter but not how to change a board to use a different filter that is unrelated to the original filter. 

             

            1. Rosie Jameson [Atlassian]

              May 15, 2013

              Thanks Matt, I have made some updates.

      2. Rainer Mueck

        May 15, 2013

        "watch/vote/comment on issues" is pretty much frustrating these days .... GHS-6754 - Getting issue details... STATUS and linked issues document this quite clearly.

  51. Laszlo Kremer

    Jun 14, 2013

    When do you plan to implement a task burndown chart plus the wallboard gadget for it?

    I am asking this because we have to move our scrum teams to the new scrumboard by November. It is a process, and we can't wait until the Classic boards will be unavailable. 

    The biggest pain currently is the lack of task burndown chart and the wallboard gadget for it. On the classic board we were able to show this with a context filter. This is heavily used on the meetings.

    Right now we only see the story point based chart witch is good, but the Product Owners usually accept the stories at the end of the sprint. So the Story point based chart does not tells much about the current progress.

    Taking a look at jira.atlassian.com's greenhopper scrumboard: it does not use Story swimlanes so movement of stories indicate the work better, but this is not the ideal scrum setup. As not being a dogfood, maybe it is not that painful for that team. For the story swimlane users (which is the default setting) it is a real problem.

    We actually create fixversions for the sprints on the new boards and try to syncronize the assigned issues with the issues in the sprints so we can see the Task burndown on the Classic board.

     

    Please comment/like if this is affecting you!

    1. Rosie Jameson [Atlassian]

      Jun 17, 2013

      Can I recommend that you conduct this discussion via comments/votes/watches on a JIRA issue? Perhaps GHS-2516 - Getting issue details... STATUS may be suitable, or alternatively could you please log an appropriate issue? Many thanks.

      1. Laszlo Kremer

        Jul 30, 2013

        For everybody who is interested in an issue burndown chart/gadget:

        GHS-3470 - Getting issue details... STATUS  

        It turned out that the ticket Rosie linked is not the relevant one. Please add your comments and vote if this is affecting you!

  52. Tim Shephard

    Jun 26, 2013

    I really like the high level over all view of the classic board for planning / prioritization purposes and how you can use the whole screen real estate.   It's one of the reasons I switched from pivotal where it was a pain constantly scrolling up and down through task lists.

  53. Fabian E.

    Aug 14, 2013

    For a cleaner view, I created several boards for the same project:

    • One for PM with columns "To Do", "In Progress", "QA" and "Done"
    • One For Developers with columns "To Do", "In Progress" and "Done"
      • The "QA" column statuses of the PM board are merged into "Done", as the task is done from the perspective of the developer
      • This also enables proper usage of the "Move to Done" button for developers
      • Several Quick Filters for filtering out resolved issues
    • One for Testers with Columns "To Do", "Verified" and "Done"
      • The "QA" column statuses of the PM board are distributed between this boards "To Do" and "Verified" columns
      • The "To Do" column statuses of the PM board are set to unmapped, thus cleaning up the crowded view for testers

    The boards are also based on different swimlane criteria to create the optimal view.

    Here's my problem:

    PM creates Sprints in the PM board. The current Sprint shows up fine in the other boards. But the future Sprints do not show up in the Developer and Tester boards.

    Is this a bug? Any workarounds?

    1. MattS

      Aug 14, 2013

      It's not a bug, it's how GH sprints work. The planning board is a big ordered list of issues and you can insert markers at various points which are your future sprints. Then the one at the top is started and that actually creates a sprint number and sets that number in the Sprint field of all the issues in the sprint. This is why you can search on open and closed sprints but not future sprints, because there's no value in the Sprint field until the sprint is started (opened)

      And the order of the issues and future sprints are defined on a per board basis, whereas Sprint field values are valid across all boards

      1. Fabian E.

        Aug 14, 2013

        Hmmm. 

        > And the order of the issues and future sprints are defined on a per board basis

        When I drag an issue up in the backlog in one of the boards, the place of the issue is synced across all other boards too. So the order of issues is not independent.

        This creates a problem:

        • In one board I plan my sprints. 
        • Its future sprints do not show up on the other boards
        • When I drag an issue up on another board (e.g. "Send to Top of Backlog"), the position gets synced across the boards
        • This issue appears in the first future sprint on the first board
        • Which is bad
        • But I do not want to forbid developers to reorder issues, as they need to prioritize bugs that arise during a sprint (related: https://jira.atlassian.com/browse/GHS-8178)

         

        1. MattS

          Aug 14, 2013

          That's true, the Rank of an issue is global across all boards. But the future sprints are really just markers in the list of ranked issues viewed on a particular board.

  54. Fabian E.

    Aug 15, 2013

    Right now, there are no automatic assignments of issues to sprints as far as I know. When creating an issue in Jira, I also cannot set the sprint right there in the create dialog. Bugs filed by QA during test in a sprint do not show up in the board in Work mode for developers, unless they are manually assigned to the sprint via the Plan mode after creation. This is easily forgotten.

    How do you cope with this problem?

    Related:  GHS-8178 - Getting issue details... STATUS



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.