A member's role on a project determines which project artifacts they are allowed to create, view, and modify. This article will explain the roles available in VersionOne and describe how they map to roles defined by some popular agile methodologies. The final section provides detailed information on the rights and privileges available to each role.
Overview
When assigning members to a project you must select a role. When drag and drop is used to make this assignment the application uses the members Default Role as the project role. For this reason it's recommended that a member's Default Role specify either the most common role played by the individual or a role that allows the individual to be the most productive on any project (i.e. Team Member). Once assigned to a project you may change this role as needed.
In addition to access, the role also determines the project artifacts a member is allowed to view and manipulate. VersionOne projects are hierarchal and roles assigned at higher levels projects apply to all child projects unless they are specifically overridden. Members not assigned a role on a given project, or any of its parents, do not see the project in the hierarchy.
From this discussion there are four (4) import factors that you need to consider when assigning roles
- Roles determine which project artifacts a member can view and manipulate.
- Default Role determines the member's role when using drag and drop to assign members to a project.
- Roles assigned to a project are inherited by all child projects
- At any level in the hierarchy a members role can be adjusted to grant or revoke privileges
Available Roles
Note: For the remainder of this document any reference to a project implies all child projects unless otherwise noted.
The VersionOne application defines eleven roles which can be used to establish the rights and privileges a member has within a given project. While this may seem exorbitant for a lightweight project management tool, there are situations which warrant the extra overhead. In order of access rights the roles are:
- System Administrator
- Member Administrator
- Project Administrator
- Project Lead
- Team Member
- Developer
- Tester
- Customer
- Requestor
- Observer
- Visitor
- Inheritor
- No Access
System Administrator: This is the most powerful role in the system and is intended only for individuals responsible for managing the system configuration. Members with this role on a project have full read/write access to that project. Additionally, they can add and remove members from the project as well as change the role for other members on the project. Finally, any member with System Administrator as their Default Role also has the ability manage other members in the system and system wide configuration values (i.e. Custom Fields).
It should be noted that users with this role are not “super users” as we typically understand System Administrators (i.e. root in Unix or Administrator in Windows). While these users have the ability to manage the system, it is possible to prevent them from seeing projects in the system. This is a powerful feature that allows you to establish an administrator that cannot view project level data or grant themselves permission to view data.
Member Administrator: This role is intended for use in organizations where member administration can be delegated. Members with this role have full read/write access to the project including the ability to add and remove members from the project and change the roles of members of the project. This user cannot perform system level configuration changes but can add and manage member accounts.
Project Administrator: This role is intended for use in organizations where project level administration can be delegated. Members with this role have full read/write access to the project including the ability to add and remove members from the project and change the roles of members of the project. This user cannot perform any system level configuration or member administration.
Project Lead: Individuals with this role are allowed to create, edit and view all project artifacts (Stories, Defects, Task, and Test, etc). Additionally, they are allowed to add releases and sprints – provided the calendar is defined by this project. This role is intended for anyone who should manage the project schedule – i.e. the Scrum Master if you are practicing Scrum.
Team Member: Individuals with this role are allowed to view, edit and create all project artifacts – including adding and removing items from a sprint. Finally, they can view, but not modify or create, the project schedule. It is recommended that you use this role as the default for all members and assign other roles only as needed.
Developer: Individuals with this role can view all project artifacts, but can only create and edit tasks, defects, issues and requests. Furthermore they can only log effort against a task. Use this role if you need to restrict a team member's access to development artifacts.
Tester: Individuals with this role can view all project artifacts but can only create and edit test, defects, issues, and requests. Furthermore they can only log effort against tests. Use this role if you need to restrict a team member's access to test artifacts.
Customer: Individuals with this role are allowed to view all project artifacts but can only create and edit stories, defects, feature groups, goals, request, issues, and tests. Use this role if you need to restrict a team member's access to business related artifacts – i.e. the Product Owner in Scrum.
Requestor: Individuals with this role are allowed to view all project artifacts but can only create and edit requests. Use this role if you need to provide access to managing input into the project, but not the project work itself.
Observer: Individuals with this role have read-only access to all project artifacts. This role is valuable for executives and anyone else who needs to track, but not edit the project.
Visitor: Individuals with this role can view stories and defects but none of the details (task, test) necessary to complete the story. This role is useful for anyone who needs an overview of the project, but does not need detail tracking information.
Inheritor: Individuals with this role can view a project in the project tree but has no access to the project contents. Use this role on higher level projects if you have read/write access to multiple low level projects and need to coordinate plans or roll-up reporting. With this role you do not have access to information in the higher level projects.
No Access: This role is used to specifically deny access to a given project. This can be beneficial if the user must have access to higher-level projects but you do not want them to know that a lower level project exists.
Using Roles
Now that we have a basic understanding of the capabilities of each role, let's consider how to use them in your organization. Two core principals of any agile methodology are open communication and trust (or open access). Based on that we can we can apply the following guidance when assigning roles:
- Make frequent use of the Team Member role. This makes a great default role because it allows you to assign the user to any project and they can become productive immediately.
- Use the Project Lead role for individuals who need to manage the schedule (i.e. product or project manager)
- Use the Observer role for individuals who want to view progress (i.e. executive management)
- Use all other roles judiciously.
The tables below apply this guidance to map VersionOne roles to roles defined by some common agile methodologies. Each table is intended to be a suggestion and you may need to alter the mapping to work within your organization.
Scrum Mapping
| Scrum Role |
VersionOne Role |
Alternate VersionOne Role1 |
| Product Owner |
Team Member |
Customer |
| Scrum Master |
Project Lead |
|
| Team Member |
Team Member |
Developer/Tester depending on users responsibilities |
XP Mapping
| XP Role |
VersionOne Role |
Alternate VersionOne Role1 |
| Customer |
Team Member |
Customer |
| Programmer |
Team Member |
Developer |
| Tester |
Team Member |
Tester |
DSDM Mapping
| Scrum Role |
VersionOne Role |
Alternate VersionOne Role1 |
| Business Sponsor |
Observer |
|
| Business Visionary |
Project Lead |
Team Member |
| Project Manager |
Project Administrator |
Project Lead |
| Technical Coordinator |
Project Lead |
Team Member |
| Team Lead |
Project Lead |
Team Member |
| Business Ambassador |
Team Member |
Customer |
| Business Analyst |
Team Member |
Customer |
| Solution Developer |
Team Member |
Developer |
| Solution Tester |
Team Member |
Tester |
| Business Advisor |
Team Member |
Customer or Visitor |
1. Alternate VersionOne Role is the one to consider if you want/need to restrict the individual 