@Bob Hunt excellent question Bob, thank you for asking.
Permissions in Jira Align are referenced to to Role Permissions, which mean the toggles in the admin console which allow the ability to for any given role to be allowed or denied the ability to broadly have the ability to see/access/perform actions based upon their assigned role.
Membership:
- Team, Program/ART, or Portfolio drives the ability for a given user or users (inside their role constraints) to access the data contained with a given "Team".
- In the case your are suggesting the user in question has membership in Team A inside your ART, however does not have membership to the ART itself (nor likely the Portfolio).
- Granting membership to the other Teams in the ART is a possibility, however likely not the best experience or maintenance pattern.
To provide this individual the ability to see/action all of the Teams contained within the ART it would be more effective to grant them membership at the ART Team level.
- The same would be true by granting them membership at the Portfolio level (they would have the ability to view/action (with some specific constraints like ranking the backlog at a Program/ART level) any ART or Team within the Portfolio.
A word of caution, however. With a large enterprise granting significant user counts membership to a given Program/ART or Portfolio(s) can/will have performance impacts.
- As an example if you have 10,000 Jira Align paid licenses (40,000 integrated users) and 300 Portfolios, if you were to grant membership rights for each of the 10,000 users on each of the 300 Portfolios the performance impacts would be broad and significant.
- It is more accurate to assess the actual membership as actors who are not "looking", but actually participating in the creation, editing, prioritizing, etc... the efforts of that given Portfolio, Program/ART, Team.
- Think about how much chaos would be created if 10,000 people had the ability to create/edit/prioritize the backlog of a single Scrum Team (comprised of 8-10 individual people). This is a good way to think about membership to these various components in Jira Align.
- Rooms, Grids, Backlogs, etc...would have load times exacerbated to a degree that would have end user impacts.
Membership Strategy:
- Target a strategy of who and how many individuals will actually interact directly with the create/edit/prioritize efforts in each space and constrain your Memberships with that in mind.
- There is no concept of a true "Read Only" role in Jira Align which means even if you were to leverage Role Toggle Restrictions to impact those users abilities to take any actions, in your control, they are still taking up membership space and not all feature/functions are controlled by Role Toggles to a deep degree.
- Those who are not actual actors (the lookers) can
- Obtain their right to view from data that can be presented from a BI tool extracting the data from Jira Align
- Through ceremonies where the actual actors can share their screen and discuss the aspects/details with said lookers
- Leverage the capture abilities to present views in Confluence or other spaces, knowing that the capture is point in time, rather than live data.
I hope this helps explain not only the feature/functions, but also a conceptual understanding of membership and strategies to leverage.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.