Skip to main content
Version: 25.0

Assigning a Project Role

This topic explains how to assign project-role in Agility

Overview

A member's Project Role grants them access to projects based on the role they play (Example: team member, project lead, tester, and so on) and determines if they can create, view, and modify project assets. This article is intended for project and member administrators responsible for assigning and managing projects membership and project role assignments.

About Project Roles

Here are a few important things to know:

  • A member's Project Role is different than their Admin Privileges role. See Roles & Project Membership for details.
  • A member may have different roles on different projects.
  • Project role assignments automatically apply to all child projects (unless explicitly changed).
  • Project role assignments made in a child project do not affect the parent or any other child projects.
  • At any level in the project tree hierarchy, a member's project role can be changed to increase or decrease project permissions.
  • You must have administrator or lead-level permissions to assign project roles to other members.

Before a project role can be assigned, the member must first be assigned to the project. This grants the member access to the project so they can see it in their Project Navigator and Project Tree.

Option 1. Assigning a Project Role on the Member Roles Page

  1. Click the hamburger menu Hamburger icon Admin > Projects > Member Roles.
  2. Expand the project tree, select a project, and click Manage next to the project name.
  3. For each member, select a role from the New Project Role or Owner List drop-down list and then select the checkbox if you want the member's name to display in the Owners list.
  4. Click Save.

Project Member Role

Option 2. Assigning a Project Role on the Project Roles Page

  1. Click the hamburger menu Hamburger icon Admin > Members > Project Roles.
  2. Click Manage next to a member's name.
  3. Expand the project tree, and then select the roles from the New Project Role or Owner List drop-down list.
  4. Click Save.

Member Project Role

Option 3. Updating a Project Role on the Member's Details Page

  1. Click the hamburger menu Hamburger icon Admin > Members and click on the member's name.
  2. Click on the Project Membership link, at the top, just below the blue and green colored top header bar to take you to the Project Membership grid.
  3. Click the wrench button to customize the grid, to include the New Project Role/.. column.(Note: Select both the Display and Edit check boxes for this column).
  4. Click through the project list, and locate the project of which the role is being updated for.
  5. Click the drop-down button under the New Project Role column and select the new role.
  6. Click the Save button.

Project Roles Summary

These project roles work well for most organizations:

  • For most members, the Team Member role is sufficient. This is a great "go to" role that grants the user basic access to any project and will allow them to begin working immediately.
  • Assign the Project Lead role to members who need to manage the schedule (e.g., Product or Project Manager).
  • Assign the Observer role to members who want to view progress (e.g., Executive Management).

Project Role Matrix

RoleDescriptionRecommended Uses...
System AdministratorThis role is not the traditional super user role you typically think of  (e.g., Root for Unix, or Administrator for Windows). While they can make some system configuration changes, their access to projects can be restricted by their project and project role assignments.
For the project(s) to which they are assigned, they have full read or write access and can add and remove members, change member roles, and manage sprints and schedules.
This role is intended for individuals who are responsible for managing system configuration settings and managing members and projects.
Member AdminFull read or write access to the project(s) to which they are assigned, including the ability perform member administration tasks and change member roles. They cannot make system configuration changes, but can manage schedules.This role is intended for use in organizations where member administration can be delegated.
Project Admin Full read or write access to the project(s) to which they are assigned. They can create and edit all project assets (backlog items, including defects, tasks, tests, etc.). They can also add or remove project members and change project roles. They cannot, however, perform any system configuration or member administration tasks.This role is intended for use in organizations where project-level administration can be delegated.
Project LeadProject Leads have similar project-level rights as Team Member, but they can also create or edit Project details to which they are assigned, Goals, Roadmaps, Rooms, and Strategic Themes. 
Team Member(Recommended for most users) Team Members can view, edit, and create all project artifacts, including adding and removing items from sprints. 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.
DeveloperDevelopers 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 only if you need to restrict a team member's access to development artifacts, otherwise you can use the Team Member role for a developer.
TesterMembers 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. Tester role can also work in Regression Planning and create Test Plans and Suites and generate Test Sets.Use this role only if you need to restrict a team member's access to test artifacts, otherwise you can use the Team Member role for a tester.
CustomerCustomers can view all project artifacts, but can only create and edit stories, defects, test sets, feature groups, goals, request, issues, and tests.Use this role to restrict a member's access to business-related artifacts (e.g., the Product Owner in Scrum).
RequestorRequestors can view all project artifacts, but can only create and edit requests.Choose this role to grant access to managing input into project, but not the project work itself.
ObserverObservers have read-only access to all project artifacts.This role is valuable for anyone (such as executives) who needs to track, but not edit a project.
Visitor Visitors can view backlog items but they cannot see any of the details (e.g., tasks, tests, etc.) below the items.This role is useful for anyone who needs an overview of a project, but does not need to see detailed tracking information.
InheritorInheritors can see a project in the project tree, but cannot access project contents.Use this role on higher-level projects if you have read or write access to multiple low-level projects and need to coordinate plans or roll-up reporting. Members do not have access to information on the higher-level projects.
No AccessThis role denies access to a given project.This role is good if you want to grant access to higher-level projects, but you do not want the member to know that a lower-level projects exist.

Project Roles

Managing Member Accounts

Planning Rooms Setup and Administration

Managing Projects or Releases

Admin Privileges Role Summary and Descriptions

Planning Rooms

Sprint or Iteration Scheduling

Project or Release Administration

Backlog Groups

Programs

Product

Release Planner