Planning board functionality in GH6 on onwards?

Question

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.

Magnus Haglund1 · Answer

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)

Peter Callies · Answer

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.

Magnus Haglund1 · Answer

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.