Work organization by Portfolios (Projects) and Teams
Best practices to plan and assign work to projects and teams: one team – many projects, many projects – one team, etc.
Brief summary of this article:
There are two ways to organize work in Targetprocess 3: Portfolios (Projects) and Teams. You can have one team that works on several portfolios (projects). Or you can have a large portfolio for a large project with several teams working on it. Any crazy mix of teams and portfolios (projects) is supported in Targetprocess 3.
In the article below, the term Project refers to Portfolio.
The Team has a name, avatar, and a list of team members. When you create a new team, you can add people to the team from the pool of active licenses, or you can invite new people. In this case, a new user will be created, and it will take one more active license.
The project has a name, color, and a list of members. So yes, people can be included both in teams and in projects. You have an option to work without teams, but it is not possible to work without Project.
Work (user story, feature, bug) has to be assigned to the project. It can be also assigned to one or several teams. If you start a new project, you may not know how many teams will work on it, so you just add user stories and features into the project backlog. You can take care of the exact assignments later on.
Teams, Projects, and Work Visibility
Some interesting questions may arise, such as: “OK, so I'm a member of the Alpha team, can I see all the projects related to the Alpha team? Can I create user stories in these projects?”. Let me explain how it works.
Suppose, we have a project called “iOS App” and one related team — iOS Team. There are 4 cases to consider (blue shows conditions):
| Project Member | Team Member | iOS App Project access | iOS Team access | Work from Team access | Work from Project access |
|---|---|---|---|---|---|
| No | No | No | No | No | No |
| Yes | No | See | See | No | See, change |
| No | Yes | See | See | See, change | No |
| Yes | Yes | See | See | See, change | See, change |
Basically, to see all the work, a user has to be assigned both to Team and to Project. If you want to restrict a user and have him see the work related to his team only, then do not assign this user to a project.
In the image below there are two teams that work on a single project. Let's say, Teddy is not assigned to the project but just assigned to Team Alpha. In this case, he will see just stories and bugs from Project X that are assigned to Team Alpha (left colored area):
User Tom is assigned to Project X directly. In this case, he will see all stories and bugs (center circle).
A work item such as a user story should always belong to a Project and can be assigned to a Team as well. You can't create a work item without any Project.
Add, Edit, and Delete Permissions
Permissions for users to add, edit and delete entities in Targetprocess are granted based on multiple different settings: type of user account, selected roles, permission settings set per roles, ownership of work items, and assignments to work items. Find more details in the dedicated articles:
- Permissions for Access to Work Items
- How to give a user permission to create Projects, Programs, Teams or Users
Administration and Management
We describe how administrators and power users can manage Project and Team membership in multiple separate articles:
- Assign People to Projects, Manage Users as Project Members
- Assign People to Teams, Manage Users as Team Members
- Assign Teams to Projects, Manage Teams in Projects
Additional Cases
In some cases, the users can view the entities that do not belong to the Projects and Teams they are members of. Here are the examples:
Service Desk
- Targetprocess users who are Creators or Requesters of a request can open it in a Service Desk, even if the request belongs to project or teams the users are not members of.
- When a request has outbound related items and the request is displayed in Service Desk, then on the detailed page of the request users see related items including numeric IDs, titles, current states even when the items belong to projects or teams the users are not members of.
Visual Reports
- When a Visual Report is configured by some user or Administrator, and the report owner shares the report with other users, then the viewers see data from the configured source such as projects and teams even when they are not members of some of the source projects or teams.
Tags
- When a tag is assigned to an entity in one of the projects or teams, then the tag appears as an available option in the auto-completion suggestions list for all the users in the system, including ones who are not members of the project or the team.
Externally Shared Views
- When a view or a dashboard is shared for external viewers then any person who knows the direct link can see everything displayed on the view. Neither membership in projects and teams nor an active Targetprocess user account is needed for such access. More information: Share View with external users.
Usage Hints and Best Practices
The interactive picture below shows some hints on how to use Targetprocess 3 if you have one team - many projects, many teams - one project, or other setups:
Many Projects and One Team
Imagine you're running a design studio called Go4. You have just one development team and many active projects. Read more.
Many Teams and Many Projects
It's time to nail down a serious thing. You work in a large company that has many teams and many projects. Sometimes one team works on a single project. Sometimes things are much more complex. Read more.
Still have a question?
We're here to help! Just contact our friendly support team.
Find out more about our APIs, Automation Rules, Mashups and custom extensions.