Tracker Workflow

Tracker Workflow is often misunderstood as a synonym for State Transitions. But Workflow is far more than that!

The term "Workflow" consists of

• Work and
• Flow.

Work

Work are all things, that need to be planned, accomplished and monitored, e.g.

• a task to execute,
• a risk to track,
• a bug to fix

Work is represented in CodeBeamer in form of Work Items.

Flow

(Work) Flow can be anything from

• Planning/Scheduling (Time and Effort, Resource allocation, etc).
• Processing (Progress will be typically reflected in the Work Item status)
• Transferring (Change of responsibility/worker)
• Splitting (Split a larger processes into smaller sub-processes, that can be processed in parallel/by different workers)
• Coodination/Orchestration

Planning/Scheduling

CodeBeamer focuses on work distribution, orchestration and monitoring.

There is internal planning support, e.g.

• Agile Planning
• Team Management

• Microsoft Project

Work Progress

In CodeBeamer, work progress will be typically reflected in the Work Item status.

Each status can be given a Meaning, that tells CodeBeamer, to which phase of item processing the status belongs to:

• Open (pending): if none of the meanings are selected.
• Obsolete
• In progress
• Resolved
• Closed

E.g. The Status options for a Task tracker

Please refer to Creating and Customizing Trackers on how work progress Meaning values are applied in tracker configuration.

There can be multiple different statuses in the same phase.

The color used for a status can be also an indicator/signal, how much attention a specific work item currently needs in this status.

Ideally, the order of status options should reflect the forward direction in the sense of work progress.

Use State Transitions to control the allowed status changes.


The CardboardView or Kanban Board, will show the work items organized in columns, where each column represents one of the processing phases above.


E.g. Example TasksCardboard:




Via these views, work progress will be visualized by work items flowing from the left to the right.

See Scrum and Kanban for the Enterprise for more information about Scrum and Kanban Board.

Flow of Responsibility

You can define specific responsibilities for work items in form of Member fields, e.g

• Assigned to
  those project/role members responsible for doing the work
  
• Supervisor
  those project/role members responsible for supervising the work
  
• etc.

Permissions

In conjunction with "Flow of Responsibility", you should define Permissions for

• Fields and
• State Transitions
  except for the initial transition from Undefined/Non-existing status to initial status, because undefined/non-existing items cannot have any Participants yet, and must therefore be granted to Roles.
  

based on

• Participants
  those Member Fields you are using for the "Flow of Responsibility"
  
• and not on Roles !

E.g. Only those users currently Assigned to a Task should be permitted to execute the state transition from In progress to Completed:

If you want to reuse the same permission settings for all transitions you can use the Apply permissions to all transitions menu item on the transition configuration page:

Two-Man Rule

Simply having defined different Allowed values (Roles) for a Member field in different states, does not necessarily enforce a "Flow of Responsibility" upon a status change. Project members can be assigned to multiple roles at the same time, and assigning a task to a user who is in both roles would satisfy both responsibility constraints. So, for example, the person responsible for fixing a bug could also be in a role (and that role assigned to one of the subsequent work item states) that allows him/her to approve the fix.

With the "Two-man rule" option

• only users (with the required role) can be selected as field values, not roles,
• selected users may not have been assigned to the work item in the previous status, neither directly nor indirectly via role.

Because "Two-man rule" enforces a change of the field value, all State Transitions, that lead into a status, where "Two-man rule" is activated for Member fields in this status, the transition should automatically clear the old field value, in order to force the user to select a new value.

E.g. In the simple bug handling process shown above, the field Assigned to has "Two-man rule" activated in status To Verify:

Staff

There might still be demand for finer control on work item level, that allows the process initiator/owner/manager to define whom (s)he wants to be allowed to play a specific Role for that specific item.

This feature is called staffing.


To enable staffing for items in a specific tracker, you must grant Permissions to the Staff field:

E.g. Only Project Admins should be allowed to edit the Staff:





The item's details screen, will then have an additional Staff tab, where you can see (and edit) which roles have been assigned dedicated members.

E.g. A task "Demonstrate Staff", where the role Developer is exclusively assigned to the user klaus and Tester to zoltan:



Staff members are a subset of the Project members in that role. Only individuals can be assigned, no roles.


E.g. Members of the CodeBeamer project:




By assigning specific staff members, you implicitly revoke that role (in conjunction with this item) from all other project members in that role.

E.g.:

• sandor, although he has the role Tester in the project, is not a Tester in respect of the task "Demonstrate Staff"
  In fact, he has no access to that task at all, because Tester was his only role.
  
• zoltan, although he is Developer and Tester in the project, loses his Developer role and only keeps Tester.

For all roles without explicit Staff assignments, the default project members in that role apply.


Using Staff gives you full control over the "Flow of Responsibility", even if it is not you, that will have to assign the work item to specific workers in some later stage. But it is you, that controls who can be assigned at all.