Defining your workflows for the Build process

When it comes to defining workflows I see a lot of people making the mistake to build state diagrams instead of workflows. Since teams and projects tend to have very different ways, or thoughts on how to work, this usually lead to fragmentation and an exponential increase in statuses, resolutions and custom fields.

So instead of focusing on every single state you have in a workflow in a long line, think of workflows as two dimensions. On the horizontal axis you move responsibility down the line towards completion. On the vertical axis you place the checklist, using subtasks, on what needs to be done in each area of responsibility.

--Insert image of axis here --

I refer to the items that move along the horizontal axis as transitional items. The most commonly used issue type for this is the User Story. The items on the vertical axis I refer to as the producing items and those are the subtasks that is added when needed. By making this distinction we can define the workflows based on the transitional items as they move between the areas of responsibility.

-- Insert image of AOR here --

In order to make things easy for the Jira users I usually design workflows with the fetch and release principle in mind. Not only will it make things clear on what is waiting to be worked on and what is in progress for each area of responsibility, it also makes it possible to measure those things, for KPI's for example. So in my designs I add status pairs for each area of responsibility, one waiting status and one active.

-- insert image of fetch and release here --

When people design workflows they are often driven by adding control to the workflow. This is done by setting hard connections (transitions) between statuses. The benefit of this is that you will have fewer options if you use the drop list in the issue view. The downside is that it is often hard to see what is connected to what and you usually need to step through several statuses to reach the desired status. This is annoying when working in boards and it forces a defined setup of AOR's that may not be applicable for each team. For example a team can have an external team doing tests or acceptance, which would force someone in the team to move statuses across those statuses even though they are not involved in those steps.

So to make the workflows flexible and still maintain structure we design the workflow with open transitions. That means that we add the allow all transition to all statuses. This will allow the teams to define their columns in their boards as they see fit based on their AOR situation.

One thing to remember when you make an open workflow is that you need to add a post function to remove resolution for all transitions except for Closed.

Lastly we and all workflows with just one closed status. I know a lot of people use the resolved status, but since that is simply an artificial status to ask for acceptance we instead add acceptance as an AOR. This makes Resolved redundant so we can remove it and by doing that we also avoid the "done, but not done" syndrome.

Based on your issue types you may need several workflows, but I have found that you usually only need three for the build process.

1. One for Tasks that follow the new->in progress->closed flow with supporting status for blocked/pending
2. One basic development flow with AOR for development, test and acceptance.
3. One extended development flow where the basic flow get Triage and Rejected for defect and incident management.

 

The Task Workflow

The Basic development Workflow (with code review)

 

The extended workflow for Defect and Incident Management