There are several threads here in the forums about multiple teams and backlogs but I haven't found one that addresses my particular situation.
I have a project (not in the JIRA sense, but in the Project sense) that is comprised of two JIRA projects (2 backlogs). We have two Scrum teams on the project. Team A will work on issues in Backlog 1 while Team B will work on issues in Backlog 1 and Backlog 2.
So in Backlog 1 I'm using the Team field to assign each Issue to whichever team will take it on. I have a Quick Filter for each team that I can use to easily see which team is working on what in any given sprint. This works well.
But I'd like to avoid asking Team B to go to the combined Backlog 1 board to see the work from this shared backlog and also go to Backlog 2 to see the work from that backlog. Is it possible create one board for them to use and still ensure the reporting isn't skewed by having items from two backlogs?
I would set up two Agile boards based on the following filters.
project = <key> AND (team is empty or team = "Team A")
project = <key> AND (team is empty or team = "Team B")
Using this both teams see the shared backlog of issues not yet allocated to a team and all items allocated to their team.
A refinement is to add a quickfilter to show team="Team A" so they only see those items allocated to Team A.
Your reports will then work correctly for each board only showing the work undertaken by each team.
I think this might not give me the project level reporting I need. Backlog 2 is much smaller so we're operating under the assumption that this will be done long before Backlog 1. So our eye is on Backlog 1 and we need the reporting on that backlog to show progress and projections based on the work no matter which team worked on it (think the Version Report, for example). With the filters you described, that wouldn't work I'm afraid.
Do you think a 3rd board that would show all would do it? The team could work from their specific boards but we do our reporting from the higher level board that shows all work.
So if you are willing to accept that Backlog 2 will be covered very quickly, then you could just look at the information for Backlog 1 and treat that as your project backlog.
Certainly having a 3rd board would allow you to see some progress reports but would lead to potential conflicts between the sprints on each board. At the moment you really need to have issues in a single sprint on a single board rather than on multiple.
Another alternative which is not fully supported is the ability to have parallel sprints which need to be enabled as they are part of the Atlassian Labs section. This would allow you to have two sprints running at the same time - one for each team. But we aware this does some weird things to reports if the velocity of the two teams are different.
Hope this helps a bit more.
Yes, we plan to treat Backlog 1 as our project backlog and I think it's going to work the way I have it set up.
And you're right about the potential conflicts of a 3rd board, however, I think I might be able to protect against that if that board is the only one that pulls from two separate backlogs. The team's sprint are already running in parallel. And because they're both pulling work from a common backlog, we have to sync up on story point sizes no matter what we do. I think that would take care of the reporting concerns. Assuming those conditions, can you think of anything I'm not thinking of?
BTW, I thought about the parallel sprint features but it just sounds half baked so I don't think I'll go there if I can at all avoid it.
The only other thing I can think of to consider is the impact of when backlog 2 is completed and what does Team B then do? Do they get redeployed on other projects or swap to dealing with issues from Backlog 1?
Depending on your answer t this will impact what happens to your sprint velocity and therefore your predictions for completion.
Team B will eventually be disbanded with some folks going to work on other projects and 1 or 2 joining Team A. So Team B will be working on issues from Backlog 1 and Backlog 2 right away. When Backlog 2 is done and that team disbands, the couple of folks staying on the project would become part of Team A and continue to help with Backlog 1 issues.
So from this information when team 2 is disbanded the following will happen.
Overall velocity will reduce (due to less team members)
Velocity of Team A will increase.
Therefore you would expect the calculated end date to be falsely reported immediately after the disbanding of team B, as it will still report based on the previous velocity.
Here's what I think I'm going to try and I'd be interested in what you think will happen:
Backlog 1: Contains the stories Team 1 and Team 2 will both work on
Backlog 2: Contains stories that only Team 2 will work on
Board 1: This board filter gets all issues where project = Backlog 1 project. I have a Quick Filters for each team that will filter based on the Team assigned to each issue. This is the one I intend to rely on for reporting of the work completed on the Backlog 1 project each sprint.
Board 2: This board filter will get all issues IN (Backlog 1 project, Backlog 2 project) AND Team = Team 2
We'll start and end the sprints at the same time for both teams. I'd expect that Board 1 would work pretty much as it does today. But I'd expect Board 2, which Team 2 would use, would show stories from Backlog 1 and Backlog 2, each grouped together by their respective sprints (but with only 1 Start Sprint button)
But I'm unsure what to expect if I start a sprint on Board 2 which has stories from two different backlogs on it. I'm particularly unsure what JIRA will do with the stories from Backlog 1.
Any predictions you can offer?
Hey Community mates! Claire here from the Software Product Marketing team. We all know software development changes rapidly, and it's often tough to keep up. But from our research, we've found the h...
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!
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