Organic board filters

Question

Hi

I have several team scrum boards which filter out team sprints and common sprints for each team.

While a sprint is always visible when created in a board, the issues moved to that sprint is not visible without editing the sprint-filter for that specific board.

I would like a feature that makes the scrum board filter grow organically when a sprint is added in that board so that issues created in a sprint that is visible on a board should be included in the board query.

Is there any way to achieve this without asking for a new feature?

Nic Brough -Adaptavist- · Answer

Ok, the boards should be matched with how you are actually going to work.

If you have one big team that does some variation of Agile Scrum (as in estimate, plan, commit to, execute in a fixed time frame and review it), then you should have one scrum board with one backlog as the starting point.  If you've got six real teams who would work better with a backlog each, then you'll want six scrum boards.  It sounds like you might have five real teams who need scrum boards, and a taskforce who may need something different.

One board is a very simple way to do it, but it is likely to get messy unless you truly do work as one big single team.  Five or six boards is going to be neater.

The main trick I find for managing this in JIRA Software is to first match the boards to how you work - not formal organisational teams or trying to silo projects, but get your actual real life scrum team(s) defined and committed to the backlog and sprint cycle.  Then get their Scrum board right.  Then, look at reporting and working with other boards that are not used for planing.

In other words, plan in the right place, and plan once.  A scrum team should plan their sprints, don't try to plan again on another level with another board that tries to take into account other teams.  Use Kanban boards to see what's in the backlog at the same time that sprints are running - they select off the same data, but won't clutter up with the sprint data.    In a situation where the scrum teams are working well with their scrum board, you'll find a Kanban overview can easily tell you everything - if it's in the backlog, it's in the backlog.  If it's done, they've done it.  Everything else is in a current sprint somewhere.  (And then, if you want to have another Kanban for just "in sprint" stuff, use the opensprints() I mentioned)

My Saxin · Answer

I'm don't really understand why either. I'm just trying to make it work with what I am given.

So to explain the facts more

I got one JIRA team, but five real teams and one taskforce team. The reason for this I've been told; is that we should share the same backlog.

Maybe I should just give up this filtering idea and instead try to find out how to make a board with a combined backlog!? Is it doable to split up the JIRA team, but still handle the backlog as common in an easy way?

Nic Brough -Adaptavist- · Answer

I don't quite understand why this board set up might be of any use to anyone, as it will obscure the whole point of having scrum boards.

But, my lack of understanding aside.  Have you tried using the function openSprints() ?  I have a feeling the JQL for your board might be "project in (x, y, z) and sprint in openSprints()".  Would that help?  I've only used it to do "a Kanban board that covers all my active stuff", but it did the trick.