We like to say that you don’t need to change your process to fit a tool, instead you need a tool that fits your process. In Targetprocess, you can create your own unique process workflow and benefit greatly from it.
A Process in Targetprocess is a set of business rules applied to the workflow of your project or your team.
A Workflow is a sequence of states and transitions an entity needs to pass through before it is done. States may vary depending on entity types, e.g. you might want a “Design” state for a User Story, but not for a Bug.
There are two types of Workflows:
A Project Workflow is the 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 Workflow for different entity types.
The other type is a Team Workflow. It is the sub-workflow of a main Project Workflow, and is associated with a Team. Team Workflows are used when there are multiple Teams working on the same Project (or multiple Projects which use the same Process) and certain Teams prefer their own way to work on items.
The Project Workflow settings for different entities are part of Process settings and include available states, their names and order, state transitions, and Roles available in the assignments area for assignable entities.
Each Project is associated with a single Process. You can use one Process for multiple Projects, or create multiple Processes so you can have different states for different Project entity types.
Take, for example, a development and a marketing team. Each team works on its own Projects and uses custom workflows for its work items. The teams create two Processes to specify custom states, terms, Roles, and transition rules. Then each team uses its own Process for its Projects.
On the picture below is a User Story’s Workflow in the development Process:
The marketing team has custom Project states for a User Story in the marketing Process.
By creating different Processes and customizing Project Workflows, you can map out the various ways your teams work on different projects.
Read more about how to customize a Project Workflow.
With Project Workflows you can reflect differences between the way you work on Projects. In most cases it provides required flexibility in fitting your Processes and prevents overcomplicating your setup. However, sometimes this is not enough. Teams may want to run entities, like User Stories and Bugs, through states that may differ from the states in a common Project Workflow.
The Team Workflow allows teams to follow their real life workflows and helps project managers to easily track progress across all teams without confusing each team’s specific workflow.
- Teams don’t do cross-work on items of the same level (cross-functional teams). In this case, a team works on an entity from the first to the last states of the entity's Workflow. For example, there are two cross functional teams – the Alpha team and the Beta team – who are working on different User Stories in the same Project. Each team uses custom states.
Each team has a team backlog of User Stories assigned to it. You can visualize the whole project backlog on a Kanban board to have a big picture of common progress, as well as see the progress of each team separately using team swimlanes.
- Teams work on the same item one after another (functional teams). On the image below you can see Analytics, Development and Dev Ops teams which are assigned to one project and have different states working on the same user stories sequentially.
To assign several teams to an entity each team should use a team workflow. It allows you to reduce the amount of manual work as an entity will be automatically passed from one team to another based on its state.
On a project Kanban board below the same user story is visualized for all teams assigned to it. However, on a team Kanban board the user story appears only when this team is responsible for it.
Check other use cases how we recommend that you consider using different setups.