Getting Your Workflow Map Right

Start and End Lanes

To accurately measure the time it takes for work to move through your delivery system, Delivery Flow requires a clear indication of when to start and stop the timing process. This is accomplished by defining the Start and End lanes within the workflow map. In simple terms, the timer begins when work enters the Start lane and halts when it reaches the End lane. Let's explore an example from Delivery Flow to illustrate this process.

Open

^{Figure 1. Workflow Map Definition in Delivery Flow}

To enhance our understanding of the settings, let's visualize the map illustrated in Figure 1. All lanes, from the starting lane to the lane just before the ending lane, are considered to be in flow. The time spent in these lanes directly contributes to the overall cycle time for the work being performed.

The workflow map above presents several options for defining the start and end lanes. For instance, this map initiates measurements once a task enters the Selected lane. This makes sense if there is an expectation that work will commence within a defined period of time, post selection. These settings allow us to track time in the Selected lane and evaluate performance against those expectations. Alternatively, we could designate the In Progress lane as the starting point, meaning the timer would begin as soon as developers start working on the task.

For the end lane, we could also make a decision to use Ready for Release. Of course, customers only start receiving the value of work once it has been released, so using Done is probably the right option here. There are scenarios however, like when you are getting familiar with flow metrics, where you might want to reduce the scope of measurements and keep the results simple.

It is essential to recognize that you are the sole authority in defining the most significant start and end points for your work. Approach this task with intention, and take the time to comprehend the implications and outcomes of your choices.

Work Lanes

The work lane flag serves as an indicator to Delivery Flow that team members are actively engaged in tasks when a work item is situated in this lane. Conversely, a wait lane is where items are queued, awaiting a team member's availability to continue work. No active work is being performed on a work item when it is in a wait lane.

Work lanes play a crucial role in calculating flow efficiency, which measures the proportion of time an item was actively worked on in relation to the total time taken. Both work and wait times contribute to the overall cycle time of a work item, providing valuable insights into the efficiency of the workflow.

With this understanding, we can identify further enhancements to the workflow map in figure 1 above. Two lanes have been designated as work lanes, although they are clearly wait lanes: On Hold and Ready for Release. The On Hold lane indicates that a work item is blocked, or perhaps an urgent matter has arisen, prompting team members to pause this work item. The Ready for Release lane signifies that work is complete and awaiting deployment to production. Removing the work lane flag from these lanes will improve the flow measurements, allowing us to gain a clearer insight into waste, flow efficiency, and queuing within the system.

New Workflow Maps and Work Lanes

When developing a new Workflow Map, Delivery Flow utilizes an existing Jira project as a template. This project will feature board lanes associated with specific statuses, each of which is categorized accordingly. Delivery Flow leverages these elements to construct the initial version of the workflow map.

Status categories play a crucial role in identifying whether a lane is designated as a work lane in a new workflow map. There are three distinct status categories in Jira, each represented visually by colour when workflows are illustrated in Jira. The following Jira Workflow serves as an example of this representation:

Open

^{Figure 4. Jira Workflow} 

Statuses that appear in grey have been assigned a status category of To Do. This means that the work has not started yet. In this example, the greyed status is also called “To Do”. Blue statuses have a status category of In Progress, meaning that work has started. Green statuses have a status category of Done. This category means work is now complete. Status categories are assigned to statuses in Jira. They can be amended there too.

When creating a workflow map, any lane that contains a status with an In Progress categorisation will be defined as a work lane. This is why lanes such as On Hold in figure 1 above are defined as work lanes when the map is first created. Workflow maps should be reviewed and if necessary, amended once created.

Impediments and Blocked Issues

In Jira, marking a work item as flagged signifies that the item is encountering an impediment, effectively indicating that it is blocked. Many teams utilize this feature to emphasize and monitor these blocked items. However, numerous organizations either remain unaware of this functionality or choose to establish a dedicated lane within their workflow for such items. A prime example of this is the On Hold lane depicted in the workflow map above.

If your team employs flagging to monitor work items that are facing obstacles, it is essential to inform Delivery Flow of this process. You can achieve this by selecting the Include flagged impediments checkbox on the Workflow Mapping admin page (see below).

Including flagged impediments will allow Delivery Flow to calculate the total duration a work item was flagged during its lifecycle. To accommodate this, Delivery Flow will introduce a new lane titled Blocked at the end of the In Flow lanes specified in the workflow map. The time spent in the flagged state will be displayed within this lane for all query results. Consequently, Blocked is a reserved lane name. If you already have a lane named Blocked, it will be renamed to Rename Lane.

Defining an On Hold lane alongside flagged impediments allows for two distinct methods of tracking blockages. However, we typically recommend that teams refrain from using both simultaneously. Instead, choose the approach that best suits your team's needs, communicate your decision clearly, and update your workflow map accordingly.