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:
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.
We would be glad to know more details if this case is relevant to you, so please don’t hesitate to share your thoughts and ideas in our voting system.
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.
- When can I assign several teams to an entity?
- To assign several teams to an entity each team should use a team workflow. Targetprocess supports the scenario when teams work on the same item one after another (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.
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.
- Why don’t I see all entities assigned to my team on the Team Kanban board?
- A board that is configured with the Team State for a particular team shows only those entities which the selected team is responsible for at the moment. When an entity is in a state which is out of this team's workflow you will not see it. Also you don't see entities that are in the Final team state in case it’s intersected with initial state of another team assigned to entity:
- How many states can I have for a team workflow?
- A Team Workflow must have at least two states: an Initial to start work and a Final to complete it.
- What if a team has a gap in its team workflow?
- Please note that when mapping team workflow states to project workflow states you can start from any project state, but there cannot be any gaps in a team workflow. You should map all team states that are between the Initial and Final team states of a team workflow to the corresponding project states.
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.
- Can my team work with several team workflows simultaneously?
- Yes, just select different team workflows for a team on different projects it works on.
- Can teams plan the same item to different team iterations or releases?
- It is not supported. You can leave your vote for the corresponding idea in our system.
- How does a team workflow correspond to a project workflow?
- A team workflow is a sub-workflow of the main project workflow. It is used by a team when it works on projects tied to this project workflow. It means that an entity can have two states: the main project state and the sub team state. It gives you freedom to choose between a project or a team perspective to track the progress depending on the level of required drilldown.