Multiple Backlogs, multiple Projects, one Sprint, one Agile Board

Question

JIRA offered us already the possibility to use multiple projects inside one Backlog and the according Sprints for the Board.

Since we are doing agency work, we have multiple projects and we are organizing our teamwork in sprints for all of these.

Now we recognized one project is bigger then all of the others, and will consume 50% of our capacities, it has much more tasks, stories etc. then the other projects.

What we would like to do is, to see the Sprint, the backlog below like usual and another backlog for that certain project, so we could easily differ to take tasks out of the "normal" backlog or out of this big project specific backlog.

We would like to have the possibility to threat both backlogs the same, move tickets out of the backlog into the sprint and back.

Can this be solved? Thanks!

Enmanuel Corvo · Answer

Maybe this helps you Combine multiple boards in single view. Basically it describes how you can achive something similar by combining multiple boards/projects into a single view using an add-on then manage your Sprints accross all the boards, gaining visibility to multiple backlogs.

Phill Fox · Answer

Hi Maximillian

Your problem is not unusual. There are a number of different approaches of which I will briefly describe a couple below.

* You can have two Agile scrum boards one for your "special" project and one for all other work. You can then track the progress on each board individually with separate sprints allowing movement to/from the backlog within the board.
I would also create a Kanban board across all projects to keep an overall view of what is happening and manage the global backlog in there.
* If you want to keep it an single board you could create a pair of quickfilters to filter the information to either your "special project" or NOT your "special project".

The way I would choose between these two approaches would be whether there are going to be other "special projects" in the future if so I would tend to choose the first approach as it is more scalable. The second approach works fine with a limited number of "Special Projects".

Others will have other approaches and it comes down to what matches closest to your business processes.

Phill