The question of using groups or roles in Jira is always active and you have people advocating both passionately. In my experience Roles is the preferred way to secure your jira instance when you are working in larger companies where user management is not handled in Jira itself.
Groups is an excellent way to quickly manage users. It requires one activity and can add a user to multiple projects in one swift action. The downside is that if you do not have control of the group itself, then it quickly becomes a black hole in your solution. This is a common issue in large organizations where the management of the groups are done outside of Jira, for example in an AD.
The separation from Jira, both for the creation of groups and the approval of adding users to a group, makes it impossible for the project owner in Jira to know who is actually in a group. On the other hand the approver on the other side know what users are in the group, but not what projects in Jira they have access to. If you also add the common issue with on boarding and off boarding users that often is handled by a central support organization, then you might have a problem keeping track of who actually have access to what information in Jira.
As I am a strong advocate of the shift-left way of working I often suggest moving to a roles based setup. This forces the Jira Project Admins to take responsibility for adding and removing users to their project. It also remove the need for support to manage the users, which speed up the process of adding and removing users AND it naturally break down larger projects to smaller ones.
This is often beneficial as many larger organization has this fear that having many projects make it difficult to work across Jira projects. This creates mega projects with hundreds of teams, which is not very efficient or fun to work in. Splitting into smaller projects also clarify where there are missing roles, which is not always clear in mega projects.
When I create my roles I try to break them down into two types: Access and logical units. Access of course dictate what actions you can take within a project and I tend to have just three roles as I think you should trust the members of your project. The roles I define are Admins, users and watchers. Admins are of course the people that can do the bulk changes and manage the projects. Users are the ones that do the actual work and watchers are people that want access to see what is going on.
The users I then break down into logical units. Not for access or permissions, but to visualize what people are actually in the project. Depending on the type of project these roles can be a bit different. If it is a development project I would add these roles:
- Management - Management people involved in the project. Typically business owners and stakeholders on the business side and project managers on the development side.
- Requirement - For the people working with requirement.
- Designing - UI/UX designers.
- Development - The developers and architects.
- Testing - Test lead, manual testers and developers of automated tests.
- Acceptance - The people in charge of accepting the solution through acceptance testing.
- Deployment - If it is applicable and there are specific deployment managers.
Doing this break down illustrate pretty clearly if the project is people in key roles. If you have 100 developers and 3 testers, then you are most likely not optimized for quality deliveries. The same thing if you have people that complain that they are both management and acceptance, then you know you are missing technical acceptance testers.
I know some companies separate internal development from external sourcing partners. This is not very good to do because it creates a gap in the information flow and if you have selected someone as your sourcing partner, then you should be able to trust them. If you have information that they should not be aware of, then make sure you separate that in a different project, not using roles or groups within the same project. It quickly becomes messy and people are uncomfortable hiding things from each other.
I know there are challenges with breaking up larger projects to smaller ones, especially when working with tests, but that is a topic for next time. Until then, do you agree with my thoughts on groups vs roles for Jira?