Use Cases in Collaboration of Multiple Teams

When you map your processes in the system, the Team Workflow gives you the unique possibility to stay flexible on a team level and have a high-level overview across all the teams on a project level without confusing each team’s specific workflow.

However, there are many scenarios for how your teams can organize a work process while running their projects. Depending on your case, we recommend that you consider using different setups.

Just one team, or several teams which don’t have differences in states, work on a project

This is the simplest case when it is enough to use Project Workflows and not overcomplicate your setup creating Team Workflows. A project workflow is a default workflow which different entities use in a project. Since it is associated with a project, all people and teams who work on a single project will use the same project workflows for different entity types.

Read more about differences between a project and a team workflow here.

Teams work on the same projects, use different states and don’t cross working on items of the same level

For example, we develop a big product which consists of many components. There are several component teams, each of which is responsible for the development of its module. Teams have different states while a project manager is interested in the high-level picture.

To reflect this case in the system we can add two team workflows for each of the component teams under the project workflow.

A project manager uses a Kanban board which shows all user stories of the project. The vertical  lanes are Project States and the horizontal lanes are Teams. This view allows a viewer to track progress of the entire product backlog and see which team is working on what.

Each team then uses its own Kanban board where the Team State is selected as the vertical lanes.

On the view below, the Reporting Team moves user stories through the states of the custom Reporting team workflow.

The project and team workflows are synchronized. When the Reporting team moves a user story from the Design to the Planned state, it will be moved to the Planned project state automatically.

Read more about how to set up and customize a team workflow.

Teams work on the same item one after another

We naturally support sequentially working teams. The most usual case for such teams is functional teams. A typical functional team consists of people performing similar functions. They are responsible for different phases of work and usually work sequentially like pipeline.

Only teams responsible for different segments of workflow may work on the same work item. So if workflow is not customized for a team, it may not be assigned to work item with other teams. Read more about a team workflows.

The main rule for the team workflows when multiple teams work on a work item is that they shouldn’t overlap with each other. With one exception, the final state for one team can overlap with the initial state for another.

For example, we have Analysts, Development and DevOps teams working sequentially on a user story in one project.

The work starts from the Analysts team. When the Analysts team moves a user story to the state which is final for it, this is a moment when the Development team takes the responsibility for it.

The Done state of the Analysts team workflow is mapped to the initial state of the Development team workflow. It allows passing a work item from one team to another automatically:

When we open a user story assigned to Analysts, Development and DevOps teams we will see these teams states under corresponding project states:

Responsible team

Once a user story is in a state which is related to a particular team you can see the Responsible icon next to the team’s name. It means that a team is working on an entity at the moment and therefore control it. In the example above the Analysts team is marked as Responsible because the user story is in the Review Analysts’s state.

When Analysts decide to finish work on the user story they are passing the item to the Development team. In the state selector it is displayed as the Open(Done for Analysts) team state and now the Development team becomes Responsible for the item:

Team Kanban board

Any team can create its own view choosing the Team State for the vertical lanes to see this team’s segment of work only. Here is an example of a view which is used by the Analytics workflow:

When the Analytics team moves a user story to the Done state it automatically goes to the Development’s Open team state (as they are mapped to the same project state) and disappears from the Analytics Kanban board:

The team state axis merges workflows for all teams selected in the Project/Team context. We recommend to select teams which use the same workflows to have a clear view of the progress.

Note: The entities, related to states that are out of the team responsibility, are not displayed on a Team’s Kanban board. We recommend to use a Project Kanban board to see all items.

Teams work on the same item simultaneously

This case is not supported as workflows of teams working on the same items shouldn’t overlap with each other. With one exception, the final state for one team can overlap with the initial state for another.

Multiple teams work on items inside a parent entity but not on the entity itself

Previously in Targetprocess, it was possible to assign multiple Teams to entities only when each Team used their own Team workflow and these workflows did not intersect. Starting from Release v.3.12.12 (July 2018), it is now possible to assign several Teams to an Epic or Feature without setting up distinct Team workflows for them. This change impacts Epics and Features only. For other entities such as User Stories, Bugs, and others - the functionality remains the same.

FAQ

Each team should use its own team workflow working on this entity's project. It is not possible to assign teams if any of them use a project workflow but not a team workflow.

Assigned teams should be responsible for different parts of an entity’s workflow. Two workflows shouldn’t overlap with each other. They can overlap only when you have the Final state of the first team workflow with any number of states of the second team workflows.

For example, on the image below Analysts and Development teams won’t be able to work on the same item as more than one states of the Analysts workflow overlap with states of the Development workflow.

The correct mapping is when only one Final state of the Analysts workflow overlaps with one or many states of the Development Workflow.

For example, you might want to have DevOps team being able to see user stories in the Development project state as well. We recommend to use two views in that case:

• a view with project states to see items outside of a team workflow.
• a view with team states to see items a team is responsible for now.