nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Release planning in Rapid Board

Matthew Weaver

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?

Accepted answers

All comments

sclowes

Hi Matthew,

One of the most requested features for GreenHopper is the ability to separate Sprint information from release information (https://jira.atlassian.com/browse/GHS-945). 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.

Thanks,
Shaun

Peter Callies

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.

Matthew Weaver

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.

Peter Callies

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!

Matthew Weaver

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

sclowes

Because our priorities change with market needs we don't publish external roadmaps (https://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+Policy). 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.

Thanks,
Shaun

Björn Wennerstr

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.

Darren Martz2

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).

Shawna Schnorr1

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.

MICHAEL OGDEN

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

sclowes

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).

MICHAEL OGDEN

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

Matt Robbins1

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.

unknown

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 https://jira.atlassian.com/browse/GHS-5484 addresses this. One more vote! :-)

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-software