Options for 2 teams working off the same backlog

[boardtc]

We are building a backog for one feature with user stories which will be worked on by 2 scrum teams.

We are not yet in a position to upgrade JIRA to 5 and so can't go to GreenHopper 5.9.x and use a RapidBoard. Not being able to add items to a Sprint (added in 5.9.1), is a blocker to replacing the task board for us.

Previously when working with mutiple teams under a same project we have used different fixVersions to filter the task board for each team.

We could also have a project context for each team, use the same FixVersion and filter on labels on issues.

I am wondering is there a smarter way. I have heard about hierarchical backlogs but not sure if relevant as we can't necessarily split our backlog functionally.

[boardtc · Accepted solution]

We have stayed with different fixVersions and find it a bit more intuitive than having different contexts. We have also added an issue type of story bug at the same level as sub-tasks.

[Shawna Schnorr]

We basically use boardtc's method.

We have a child fix version for each team, which rolls up under a sprint, then the sprint fix versions roll up under the release.

I think heirarchical backlogs are just another form of the child-parent fixversions. So why split out the backlog ... you only want to see it split out when the work is "in sprint".

[Juan Boscardin]

Folks, Nowadays Jira Server version have had for a long time the ability to create boards based on the users, etc. So we use that and run parallel sprints for a  project (one per each of the three sub teams working on this same product backlog).

But Jira reports are a mess with parallel sprints, specially gadgets and velocity. Do you have a solution for that?

Thanks a lot 

[Renjith Pillai]

To handle multiple teams, it is not needed to have multiple fixVersions, as you said different contexts are sufficient. We had a Assignee changed to the team email-id and contexts were created based on this. That was sufficient to handle multiple teams.

[boardtc]

Thanks. Do you see the team contexts as filtering on a label? That means that any new issues created (bugs) need to be laballed as well, I was hoping to avoid this step which is error prone. That's why I was wondeirng if there were smarter options.

[Renjith Pillai]

No, we created the filters with two conditions.

• With assignee as any of the team member or the common team email id

OR

• Reporter as any of the team members (for Technical Tasks for Task Board usage for Sprint Burn Down)