How to rank/groom issues across multiple backlogs

[Tim.Dutton]

We have several backlogs, which are each independently groomed by the relevant backlog Product Owner.

Our engineering team pick off items from all these backlogs, so how do they decide whether to pick off from the top of Backlog A, or Backlog B?

How can we run a second-level grooming session which presents issues from ALL backlogs into a single view, where we can then drag and rank them relative to each other so that Engineering have clear direction on the next overall priority across ALL backlogs?

[Trudy Claspill · Accepted solution]

Hello @Tim.Dutton 

Welcome to the community.

You could make another board based on a filter that encompasses all the separate backlogs, so all issue will appear on one board. On that board the issues from the backlogs can be ranked against each other.

However, if the ranking of two issues from Backlog 1 are changed in this new board, that will change the ranking of those same issues in Backlog 1 itself. Backlog ranking is global, not board specific.

See https://www.jirastrategy.com/questions/how-does-jira-issue-ranking-work

[Bill Sheboy]

Hi @Tim.Dutton -- Welcome to the Atlassian Community!

Yes, and...to what Trudy notes:

You seem to be describing that your engineering team is doing work in support of multiple stakeholder teams (via the refined work from Product Owners).  Some clarifying questions may help:

• If your engineering team is doing the work, why is that work in other teams' backlogs?
• Have you instead considered having an intake process, and asking the POs to add requests to your backlog?
  • Then collaborate with your stakeholder POs to rank these requests together
  • This transparency would align everyone on how work is ranked, and give stakeholder POs an idea when their requests would get done

Kind regards,
Bill

[Nic Brough -Adaptavist-]

I couldn't agree with @Bill Sheboy more!

Specifically: 

• If your engineering team is doing the work, why is that work in other teams' backlogs?

A backlog is supposed to be a pile of issues that a single team needs to deal with.   A team should never be looking at other teams' backlog for their work. 

There's nothing wrong with visualising, refining or even re-ranking issues across many backlogs in one place (having an overarching backlog that effectively compounds several others), but the question "do we pick from backlog A or B" is never a question your engineering team should be asking.  They should be asking "what is at the top of our backlog?"  It's also fine to have an issue in many backlogs, up until one team accepts responsibility for it.

I also agree with @Trudy Claspill on the multiple-board views.

For each team, have a single "official" board for them to work on (a board is actually two things that are inextricably entwined - a backlog and a board-view).

Then create other boards that look at the same issues that one or more team boards look at.  And use their wider views to do the cross-team refinement and ranking.  Because changes in there will be on the individual issues, each team will have their views (boards and backlogs) ordered the way the whole organisation needs, without piling them up with a whole load of issues they won't have any responsibility for.

[Tim.Dutton]

Thanks for your feedback @Nic Brough -Adaptavist- , @Trudy Claspill , @Bill Sheboy .  I've inherited the team and still working through how we are operating. 

Essentially at the moment we have:

- one JIRA project for each project A, project B, project C etc. 

- one JIRA project for Problems coming into Service Desk which need an Engineering fix

- a number of projects for different business areas, where small changes (tasks) are captured

Our engineering teams (UI, Services, DB) are picking off the backlogs of these projects.  They are a shared resource.  I am trying to ensure that they are always working on the right priorities: at the moment each backlog is groomed, but we don't have an overarching backlog view so that we can see relative rank of ALL issues.

I think you're all recommending that:

1. We have a backlog per funnel (Project, Service Desk Requests, Small change).  The responsible PO grooms their backlog as required.

2. We have a consolidated board covering all issues, and do a second-tier grooming of this to do the cross-team refinement and ranking.

3. We have a board per team, meaning each team has a single view of its ranked work items (UI, Services, DB)

OR

1. We have a single backlog, and use metadata to differentiate the requesting area (Project, Service Desk Requests, Small change).

2. All the POs get together to do grooming (cross-team refinement and ranking)

3. We have a board per team, meaning each team has a single view of its ranked work items (UI, Services, DB)

Have I caught this right, and which of the two, in your experience, do you recommend?

[Nic Brough -Adaptavist-]

No, neither of those options.

• Create a backlog (and hence board) for each team. 
  • You could do that by creating a project for each team and telling the board to simply look at that project (Board filter of "Project = XYZ")
  •  Or you could be a bit more clever and do it with a custom field or label - when something is for Team XYZ, put that in a field, or label, and have the team's board select.  A board filter would be "customfield = XYZ" or "Label = XYZ".  You can of course get a lot more clever than that.
  • If you are going to do this by field or label, then you'll need some process that gets your people to put the right identifiers on each issue, either as it is created or maybe as a triage-like process.  You could even leave the field empty until your POs are doing refinement, as they would be deciding which team it goes to at that point
• The product owner would be refining the backlogs for the team (POs are part of the development team, albeit possibly more than one!)
• Then, yes, you are probably going to want a consolidated board (especially if your POs are the ones putting the team on each issue).  That can be done by combining all the team's board filters (so "project in (ABC, RST, XYZ)" or "label in (ABC, RST, XYZ)")

[Tim.Dutton]

Perfect, makes sense @Nic Brough -Adaptavist-  and thank you!