We are in the planning stages of implementing Agile Accelerator and are struggling with establishing the structure to fit our organization. Our "Teams" are mainly structured around projects (typically a project is a Salesforce application). Team members work on multiple apps at the same time. My initial thought is to create a Team for every app. However, I'm not quite sure what to do with the Product Tag. One thought is to use the Product Tag represent components within a given app. From what I understand the Product Tags cannot be shared across teams.
I want to make sure we setup the structure correctly so that it will scale without a lot of rework. Any feedback on initial setup would be appreciated. Thank you.
Very good questions, and conversation points. We too are rolling out Agile in our organization and these same conversation points have come up.
Team = you may want to view teams as the logical grouping of people that are performing the work. Teams are not necessarily grouped by a project or product but rather a domain of knowledge where they may work on multiple projects and products. So for us it has been common to have a Team defined by the domain within the Business they work with or support e.g. Accounting (Team), CODA (Product), Billing Reports (Theme)
Product Tags = these have been used to represent systems or applications that a given team supports or works on. So some teams may only have one product tag that is named very similar to their team because that is the focus of their domain knowledge. Where another team might have several product tags because the support and work on several systems or applications. At its root a product tag is really a way to group information within SFAA.
Components within an App = we have been utilize themes for this. Since a work item might span multiple areas of a product we can assign many themes on a work item like (login, admin, reporting etc...) A theme is just a description tag for anything you might want to report on in SFAA
Projects \ Teams = I would try to decouple your teams from being set up for individual projects. Teams in theory are sustained over a long period of time and get fed work as new projects come up. Epics can be used to represent projects or long running initiatives which is what we have been doing to ease the transition from a traditional waterfall project management approach to agile. Epics are large user stories, large initiatives, or groupings of users stories. Some good info regarding this in mountain goat's blog
https://www.mountaingoatsoftware.com/blog/stories-epics-and-themes
