Release planning in Rapid Board

One of the features we really like about the existing planning board is the ability to drag & drop issues (stories, bugs, etc.) directly into a release in order to do release planning. From what I can tell, this is not currently available in the Rapid Board.

Is there a way to do this in the rapid board, or is this planned functionality in the future?

6 answers

Another great thing about the Rapid Board is that separates Project from sprints. We want to use the JIRA "project" construct to represent Products (like Atlassian does). However, we have teams that work on issues from multiple products (projects) in the course of a release. With the current planning board being tied to Project and Version, it is impossible for us to have a coherent release and sprint plan for a team that crosses projects/products so we've manufactured a custom Product field within one master project - ugh!

Yes, we have the same issue. Multiple teams with a few different projects/products while managing releases of them. We want to see the velocity of a team but also how the project/product is doing with the velocity of multiple teams on it. It's a complex reporting problem.

The rapid boards give us reporting by team no matter what product/project they are working on. That is awesome! They do not appear to give us reporting/projections on releases.

Actually, what would be awesome is an additional rapid board that is ONLY for reporting. What if it provided story point velocity and estimation to completion at the current pace. Ideally it would allow for multiple projections based on different criteria (ex: minimal marketable features versus all in).

Because our priorities change with market needs we don't publish external roadmaps ( I do understand that release planning is a significant problem, but conflating Sprint planning and Release planning (as in the current GreenHopper) oversimplifies both.

GreenHopper aims to be a best of breed Agile Planning tool, the fact that it can be used to drag and drop issues in to releases is a side benefit for some users. We would ideally like to address release planning directly in either JIRA or some other fashion. This is not something we're focusing on right now but we'd like to look at it in the future.


JIRA bulk opertion is a workable solution for now, but it's it would be a lot nicer if we didn't have to leave GH.

What would make sense is to list the involved JIRA projects in the Rapid Board and let us release them individually.

I agree it would be a lot nicer if we didn't have to leave GH to assign issues to a release. With the new rapod board I can no longer do my planning the way I did it in the Classic GH. As for project being able to release individually that would be good for those who have different release schedule but for those who have multiple projects on the same schedule it would be nice to do it all at once and assign issues to the release directly in GH.

Shaun I think this needs to be looked at more.

My team is going to really miss being able to drag and drop issues into releases from within GreenHopper. This has been a mainstay of how we do planning. (a) At the outset of a release, we'll pull in all the stories that we hope to accomplish. (b) At the beginning of each sprint, the team then commits to the issues they are going to complete that week. (c) Often enough, we'll end up pulling issues out of the release due to priority changes, resource changes, release date changes, or all the other things that make agile planning necessary. As far as I can tell, (a) and (c) are going to be more cumbersome now.

I'm warming up to the idea of disconnecting sprints from releases, since my team works on several projects at once and I can see the benefit of tracking everything within a single sprint. But the potential hit to release planning is what I'm worried about.

I'm trying not to be that guy that doesn't like change (nobody likes that guy :-) but I feel like I'm losing functionality that made my team more efficient.

You guys do an awesome job with your product and I appreciate your dedication to continuous improvement. Don't stop that. I'm just trying to wrap my head around this change and understand how my team can still plan and adjust releases as efficiently as we could before.

Update: Would it be possible to bulk edit issues within the Rapid Board? e.g. select multiple issues and change the Fix Version for all of them at the same time? This would allow my team to quickly assign issues to releases and would really bridge the gap between how we did release planning in the past and how we'll need to do it now. Looks like addresses this. One more vote! :-)

Hi Jared,

Is there benefit to working the other way and only assigning the issues to the fix version when the sprint begins (and there's therefore commitment that they will make it in to that sprint)? You can do that today from the 'View in Issue Navigator' link in the Sprint Report by using Bulk Edit.

We do plan on implementing further functionality around release planning soon but I'm interested in your thoughts on how we can prevent pre-assignment to fix versions ending up with issues being added to versions then slipping from version to version, it seems like the sprint flow with incompete issues going back to the backlog ready for the next sprint fluidly addresses that better.



Thanks for the quick response, it's really appreciated. We've been using the Rapid Board for over a week now and we like it. Simple and concise, it is certainly easier for developers' day-to-day work and for sprint planning. That said, for those doing the release planning (e.g. me :-) the loss of a quick way to assign stories to releases is a bit of a hit.

While I understand that adding issues to a release after the sprint is completed may be a best practice, the reality of how we do business is that features are added to releases in advance. There are numerous software and hardware dependencies that we have to deal with, and as such there is a need to know what will be included in future releases to facilitate communication and coordination between product management, the various engineering teams, and sales.

I am also unsure how you can reliably use a release burn down chart if you can't add all the stories to the release in advance. My management, which is new to agile, has just started allowing me to use burn down charts to show them that my software team is on track for a given release. This is a huge win as it means I don't have to put together additional documentation to prove we're moving at the pace necessary. Again, an argument for assigning stories to releases in advance.

Hopefully that adds additional substance to my previous comments.


Hi Matthew,

One of the most requested features for GreenHopper is the ability to separate Sprint information from release information ( As a result the Rapid Board does not overload the fixVersion to indicate a Sprint.

We don't intend on changing the Rapid Board to assign issues to versions, however we do plan on adding the ability to see all the issues from a Sprint in the issue navigator. From there you can use a bulk edit to quickly assign them all to a fix version.

We do intend on implementing the ability to plan multiple sprints in advance.


Shaun, I think GHS-945 makes sense, but there needs to be some way to conduct release planning and tracking, preferably without needing to flip back and forth between a rapid board and the issue navigator.

Your description of assigning all issues from a sprint to a release is backwards from our planning process. We work top-down, not bottom-up. We work from epics and features down to stories, sizing and prioritizing at all levels. Most of our teams know their release velocity so they have an idea of what will fit in the release. Once we've got the stories assigned to a release, then we work through the process of assigning the stories to sprints.

Whether this is right or wrong, I think the tool needs to support it.

In Scrum, sprints roll up into a release. I need a way to identify sprints as part of a release.

Perhaps planning multiple sprints will meet the release-planning need for small teams that know which sprints are part of a release. However, I'm having a hard time understanding how someone with limited understanding of a project will know which sprints form a release. For example, if I've got Sprints 3-7 "planned", but only 3-6 are part of a release, how would someone know that from looking at the Rapid Board?

How can I report or generate charts for a release? I currently use burn up, burn down, and cumulative flow charts to monitor the release plan of individual teams and well as the release plan across teams (we have multiple teams contributing to an enterprise release - don't get me started on needing to set up versions in each project). My assumption is that each team will have their own Rapid Board. Will there be JQL support to allow filtering of issues based on Rapid Board?

Is there any way to view the roadmap/backlog of upcoming Greenhopper functionality? That might alleiviate some of my concerns.

I agree that separating Sprints from Releases is a wonderful thing. Our fix version list is getting quite cluttered with sprints. However, we still need support for a higher level of planning than at the sprint level.

We will typically assemble a bunch of stories, bugs, etc. and say those issues plan to be tackled in version X. They get assigned to a Fix Version and are prioritized. Our sprint teams then work through that backlog. Of course, things on the backlog may be added, removed or reprioritized throughout the release. We mainly need a visual way to manage this backlog.

Shaun, how would you recommend this being done in Greenhopper in the future? It seems unreasonable to manually go into each item and edit the fix version. The existing planning board has a great way to do this... by dragging the issue(s) into the release on the right-hand side of the board.

I found issue GHS-3717 in the Greenhopper backlog. This would solve the problem.

Matthew, check the comment I added to GHS-3717.

BTW, the project-version dependency drives me crazy!

I would like to see a release planning method that is more akin to multiple (draggable) markers in the backlog, rather than moving items out of the backlog into a fixversion/release.

We also like the planning board, but think we could survive with the scrum/sprint planning view IF we could do the same things we do with versions:

1. correspond a sprint to a version

2. define release date for version/sprint

3. have multiple sprints active in parallel

4. be able to switch between sprints in the work view of the rapid board

5. 'release' any sprint in any order

Ok, I don't think we will (1) or (2) because they would simply reproduce the problem that led us to separate sprint from version in the first place.

Agreed we would like to do (3), (4) and (5).

ok, I'm not sure about others but that sounds like a workable solution for our needs. thanks!

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Jan 29, 2019 in Jira Software

Transforming Jira Software projects for general project management purposes

...It's true that there are projects in Jira; but they are merely a way to cut off issues, to tell them apart from other sections of work and to apply rules that are specific to that team (the schemes)....

198 views 0 6
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you