Optimizing the Workflow

As you can see, the preceding diagram is too complicated to be useful. To simplify the workflow you can eliminate the Dispatch action because the routing rules in Issue Manager take care of distributing bugs to the correct inboxes. In the preceding diagram you can delete the New-Bug state and the Dispatch action and start the bug in a state where a QA engineer can review it. You might call this the Unreviewed state.

Another flaw in the workflow is the virtually repetitive states. Using Issue Manager’s methodology, you can eliminate redundant states by assigning reason codes to actions. For each action that requires a reason code, devise a brief, descriptive keyword. For a full explanation of reason codes, please read “Reason codes”. To identify redundancies, look for repeated patterns in the workflow. For example, in the previous diagram, the last row of states (Not-a-Bug, Deferred, Not-Repro, and Fixed) can be collapsed into the single state of Closed with a different reason code for each action (for example, Closed/Not-a-Bug, Closed/Fixed).

The next-to-last row can also be collapsed into a single state that recognizes QA’s role in verifying Development’s claims. You might call this state QAReady. You can use reason codes here to explain why a bug has changed states (for example, a bug arrives in the QA-Ready state with a reason code of Fixed or Deferred). The four Rejected actions taken by QA can be collapsed into a single Rejected action. Similarly, the four Verified actions taken by QA can be collapsed into a single Verified action.

Example