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.
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.
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|
|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.
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:
We describe how administrators and power users can manage Project and Team membership in multiple separate articles:
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:
Externally Shared Views
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:
Imagine you're running a design studio called Go4. You have just one development team and many active projects. Read more.
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.