Planning board functionality in GH6 on onwards?

With the promotion of the Rapid board as the one and only board in GH 6 we are really missing the planning board functionality (or will be when it is fully deprecated).

For our maintenence tasks we don't use sprints, and the old planning board was a great place to plan releases in advance and manually tag issues to each release. We used this along with a Kanban rapid board to manage issue flow. This functionality is basically impossible to manage in a proper way using only rapid boards. The large amount of systems we maintain with indivudual component releases would flood the system with boards if we would use a rapid board for each release and use it's release functionality.

So my question is if there is any plan to migrate this planning functionality to the Kanban rapid board in the future? I could see it, or a similar function, as the "plan" part of the Kanban rapid board which currently has no fuction.

2 answers

I don't think I really understand the process you're describing. How does your Kanban rapid board inter-relate to the release planning you're doing on the planning board?

We definitely won't be migrating the planning board as it stands, but we'll look at features to make release planning easier (though probably not drag and drop to 'version' buckets).

The planning board will definitely not be deprecated any time soon.


Sad to hear, as

drag and drop to 'version'

is one of our most used features here and definetly a reason to use the classic boards

We use large Kanban boards that span multiple projects with different component releases and also a lot of maintenence tasks that the team is performing that never affects the code in any way, and as such is never part of any release. We use the planning board seperately to create releases and map the subset of issues that are supposed to be a part of these to their respective releases.

So I agree with Thomas H. that our most used feature in GH, along with the kanban board itself, is the release planning.

Magnus, I was lamenting the loss of release planning in the rapid board because I also had grown attached to the version buckets. However, the rapid board has really grown on me and the functionality has grown to the point that we are migrating entirely away from the planning board for our next release which begins next month.

I'm planning on each team having a board. Each board will have a quick filter per release (i.e. not a board per release as I think you are fearing) so the team can quickly filter the rapid board backlog down to list of items that are planned for a specific release. If they want to add something to a release, they edit the item to adjust the fix version.

For maintenance tasks you describe, you wouldn't even need to set a fix version. I assume there is an attribute that identifies these so you could have a quick filter to show only those tasks.

I also have a large Kanban board that encompasses everything being worked by all teams so I can see overall progress.

I think we have different requirements, but perhaps there's something useful in my example. By playing with the rapid board enough, I've learned that I'm really going to rely heavily on quick filters.

Peter, it is an intresting which I hadn't thought of. Although for us I think it would not be feasible. To be more exact, we have about 17 people working with about 15 systems where each system may have several standalone components where each component may have a release planned. It would be alot of boards to keep track off. It is, for us, easier to use the planning board for each system to create and plan each release. We use the boards to keep track of the teams the daily work, keeping track of prioritized issues (issues that are bound to SLAs), and what each member of the team is working on.

Just using boards I feel is not scalable for us.

(And for mainenance tasks we have for each system a fix version where we dump them in)

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Feb 26, 2019 in Jira Software

How to prevent the propagation of unused project schemes, workflows & screens in Jira software

Atlassian ranks project attributes as the third most important factor impacting performance in the category of data. It’s not surprising, since project attributes are precisely the rules used to ma...

612 views 0 7
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