Roles, teams & projects – iceScrum

Documentation This documentation applies only to iceScrum v7.
For old iceScrum R6, read the documentation or migrate.


Team, project and server roles

In iceScrum, product development is organized by Project. A Team can work on zero, one or many Projects but every Project must have one and only one Team working on it. In addition to its Team, a Project can have users directly attached to it.

The major Scrum roles are available in iceScrum:

  • Team roles: a development team consists of Team Members (TM) with one or many of them being ScrumMasters (SM).
  • Project roles: the project has one or many Product Owners (PO) and optionally external people interested in the product: StakeHolders (SH).

In order to adapt to real-life situations, some of the theoretical rules associated with these roles have been relaxed, e.g. it is possible to have more than one SM and more than one PO in a team and it is possible to be both SM and PO.

For practical purposes, iceScrum also offers additional roles:

  • The team Owner
  • The Anonymous SH: a non-registered user who browses a public project
  • The server Administrator (Admin)


In order to belong to a team or a project, a user must exist. The default way to create a user is that users register by themselves. Some Apps allow administrator to batch create users or even automatically create them through an external authentication method, see the corresponding Apps.

Users cannot choose their role: roles are either automatically granted through the iceScrum workflow or explicitly granted by other users having sufficient permissions.

New users cannot spontaneously join an existing project, they must be added by the Owner or the SM who will choose their role. As a Owner or SM, you must wait for users to be created in order to grant them roles, unless you use the invitation feature explained in the next section.

If you are a Team Member / ScrumMaster then you can view the team and leave it. If you are Product Owner or Stakeholder, there is no way to leave the project so you will need to ask the Owner or a ScrumMaster to remove you from the project.


You can manage project / team membership of persons who do not have an iceScrum account yet thanks to invitations.

If you use your own server, invitations are not enabled by default so you need to enable them manually, which requires that an email server is properly configured and that user registration is enabled. You will find more information about this configuration in the Install Guide and the Server administration documentation.

To invite someone, type their email in the user search field and click on the result. You can grant them any role just like you would do with registered users. They will receive an email for each team / project you have invited them in with a link to register on iceScrum. When they register with this link, they are automatically added to the teams / projects they have been invited to.

Permissions by role

The section below goes into the details of each role, starting with the one that has the least permissions. Each role is defined in comparison to the role preceding it so we recommend that you read them in sequence. The scope of each role is provided in parenthesis.

Anonymous StakeHolder (Project)

This role exists only for unregistered users on public projects (thus, you cannot assign this role). For such projects, Anonymous SH have the following permission:

  • Read-only access to the views allowed for SH in the project settings

By default, all the project views are allowed but this can be customized.

That is all, but it is already useful for information visibility purposes. In order to suggest stories, an Anonymous SH can register and become regular SH and get the permissions described below.

StakeHolder (Project)

StakeHolders must be registered in iceScrum. Any registered user is automatically SH on all public projects, no manual action is needed. For private projects, this role must be explicitly granted by the Owner or SM of the Team.

For both public and private projects, SH have the Anonymous SH permission, plus:

  • Import projects (if allowed in the server configuration)
  • Create projects (if allowed in the server configuration)
  • Create stories in the project sandbox (“Suggested” state)
  • Update and delete the stories they have suggested as long as they are in the “Suggested” state
  • Comment stories
  • Follow stories (being notified when stories are updated)

Team Member (Team)

Team Members must be registered and are explicitly part of the team working on the project. TM have the permissions of the SH, plus:

  • Browse all views (including the ones not allowed to SH)
  • Estimate stories
  • Copy stories
  • Create, update and delete acceptance tests on stories
  • Create tasks
  • Interact with a subset of tasks: the ones with no responsible, the ones they are responsible for and the ones they have created

ScrumMaster (Team)

ScrumMasters have the permissions of the TM, plus:

  • Update the project settings
  • Update the project Product Owners and Stakeholders
  • Enable and disable Apps on the project
  • Manage the team by adding/removing members, changing roles and update the team name
  • Export a project
  • Archive a project (but not unarchive it, be careful!)
  • Plan, unplan and shift stories
  • Create, activate, stop and delete releases
  • Create, activate, stop and delete sprints
  • Write a Definition of Done and the sprint Retrospective
  • Manage tasks regardless of their state and responsible
  • Delete any comment

Product Owner (Project)

Product Owners have the permissions of the SM, plus:

  • Create, update and delete features and actors
  • Update and delete any story
  • Mark stories from the sandbox as “Accepted” to move them to the backlog
  • Prioritize features (by reordering them)
  • Prioritize stories in the backlog and in sprints (by reordering them)
  • Split a story
  • Create stories in the Backlog (“Accepted” state)
  • Change the creator of a story
  • Mark stories as done (and “undone”)
  • Return a story to the sandbox

However, some permissions of the SM are not available to regular PO:

  • Estimate stories
  • Update the project settings
  • Update the project Product Owners and Stakeholders
  • Enable and disable Apps on the project
  • Manage the team by adding/removing members, changing roles and update the team name
  • Manage tasks that they are not responsible for nor creator

A PO can also be SM, this is the only project / team role combination that is allowed. It has no sense from a theoretical point of view but it makes easier for one person to be able to do almost everything on the project, which can come in handy for small teams.

Team Owner (Team)

The role of Owner is given to the user who creates a team, so there is only one Owner per team. They have all the permissions on the team and the projects associated to the team. That means all the PO and SM permissions, plus:

  • Delete a team if it is not associated to any project
  • Associate a project to a team
  • Switch team on a project
  • Delete a project associated to a team they own

Administrator (Server)

The Admin has total control over all projects. It is created during the setup wizard at the server first startup.

In addition to the regular permissions, the Administrator is the only person who can change the Owner for a team and restore an archived project.

With paying licenses, the Administrator can benefit from powerful Apps.

Try it for free now
All you need for your Agile project management