Here's an interesting one: Multiple Agile teams across multiple related, but separate products...

I should also note that we have three sets of sprint planning/estimation/review/retros for the three different agile teams.

In Scrum, there should be one Product Backlog for each separate Product, each of which has a clear Product Owner. There can be multiple Development Teams which draw work from the same Product Backlog, and they will plan their own Sprint Backlogs which will result in an integrated and releasable product Increment every Sprint.

- What are the "team backlogs" you refer to?

- Why is there a desire to combine work or workflows across Products and Product Backlogs which are supposedly separate?

- Why do releases span multiple products?

@Ian:  All good and valid points/questions.  Such is my current predicament.

In Scrum, there should be one Product Backlog for each separate Product, each of which has a clear Product Owner. 

• That'd be me, for all three products.

- What are the "team backlogs" you refer to?

• We quite literally have 3 additional projects in Jira, one for each team.  This is in addition to the Product projects in Jira.  Team stories will actually link back to bugs/improvements/new features in the Project projects.

- Why is there a desire to combine work or workflows across Products and Product Backlogs which are supposedly separate?   - Why do releases span multiple products?

• Our system consists of three main components, each defined as its own Product:

1. A configuration tool
2. A central processing / execution / etc application
3. Software that resides on various hardware elements distributed across large geo footprints

• We have three teams available to work on the three components, but each component may not have work during a given sprint (sprints line up for all three Products), so we cannot dedicate one team per component.  At times, also, work must be completed across multiple components in order to create new features (or bugs may span across components).  We're left in a situation where the "Products" (components) are not quite disparate and not quite unified.  We have three teams because the number of folks, if combined, would be quite large.
• A new feature or bug is dedicated to a specific team, who handle all work across the three components, in one or more sprints.

My main challenge, something that I'm looking to solve, is to eliminate the team Jira projects and associated backlogs, and work solely from the Product projects (backlogs).  Challenge is to maintain the current cross-team/cross-Product workflow while doing this, without creating a ton of overhead, complication, or 20 cross-links for every PBI.

Hi John,

Going to add to your conversation, with maybe another twist.  Ian, maybe you have some exposure to this as well.

We have a scenario where in one functional product area, we have 4 applications, different technologies (think near end of life/ legacy).   Right now we have 2 scrum teams that cover 2 applications each, both with it's own backlog, own product owner.   The backlog / funding for all applications is being reduced, to the point where one scrum team could support all 4 applications if not for the varied technologies.     Looking for a model or examples of how this has been handled in other organizations.

Assuming the skills were there, a single Development Team could support 4 products via 1 week sprints in rotation. Each sprint would service a different product, and each product would thus be worked on once a month for a different Product Owner. The provision of such servicing might be the Sprint Goal in each case.

Thanks Ian.

That's our challenge, the assumption :)    The apps each come with different code bases, (C++, Java, PLSQL, etc) so varied skill sets    I've not seen a model where you have 1 or 2 person scrum teams, but neither have I seen a model where you have 1 full scrum team supporting 3 or 4 technologies.    Not sure it exists.   

Hey John, did you ever get a resolution to this? I have a client with a similar issue and I wanted saw your post while looking for information on how they could resolve the issue and if someone out there had done it before.

Some important notes about Jira:

(1) Issues are created within a project

(2) Boards are built off of queries, and thus can display issues from multiple projects

(3) Reports (burndown charts, etc) are based on boards

(4) Workflows are applied to projects

(5) Different issue types within the same project can have different workflows

(6) You can reuse the same workflow on other projects (no need to recreate it)

I recommend adding a custom field to all issues called "team" that will have a drop-down of the three teams. You can then create a board for each team, by having your query filter issues based on that field. Thus, each team will have a single board where they can manage work.

Note that if you don't edit the permissions on a query for others to be able to see it, only you will be able to see the board made from that query. 

It sounds like you may also want to edit the workflow scheme so that features (or something else higher up in the hierarchy) use a workflow that requires additional review checkpoints that are not in the workflow for issues lower down in the hierarchy. 



(PS. I know that this reply is years too late for anyone already on the thread, but perhaps it will help someone new.)

Hello @john @Brandon, 

I am curious to know what your solution was to the original problem

(1) Multiple small scrum teams (developers ranging from 1 to 4 max, in each team).

(2) Different product vision for each of the scrum teams

Is it even an efficient use of SM or PO in a scrum team with 1 or 2 developers  ? Which is the best Agile methodology to use for small scrum teams ?