To have a broader understanding of this tutorial, it is advised to read the tutorial States and directions of work items before moving forward.
Introduction
Pacemkr offers the ability to filter your data by workflow stages (or columns). This means you can select the stages you want based on the perspective you want to have on your work items.
For example, you could have the following workflow:
For whatever reason, you might want to look at work items from the Building to ‘Done’ columns:
Or maybe it’s the other way around and you want to look from the ‘To Do’ to ‘Building’ columns.
The rest of this tutorial will highlight different situations when you select specific columns of your workflow. It can give you the impression that Pacemkr doesn’t calculate correctly your metrics but once you have a strong understanding of how specific scenarios are considered, we hope it will make more sense.
Cycle time
As you select a subset of your workflow, your cycle times and the overall Service Level Expectation can give fluctuating values. It is important to consider the following situations as they are the most probable cause of changes in cycle time values.
Selecting only the first and last columns
There are situations where some of your work items go directly from your first to last column without touching any other columns. This situation can happen when you are cleaning your list of things to do. Some items are already done or will never materialize.
For these reasons, you send your work items to the ‘Done’ column like in the following image:
Let’s use the grid notation to calculate its cycle time. In the following image, the cycle time of work item A is 5 days (Friday – Monday + 1).
Now let’s say the user only wants to look from ‘Building’ to ‘Done’. By only selecting those columns in Pacemkr, our workflow will look like this:
Using the grid notation, we have:
How can we calculate the cycle time of work item A when we don’t have its starting time, i.e. Monday?
There are 2 options here:
- Option 1: Stipulate that work item A entered in Building on Monday to keep a cycle time of 5 days
- Option 2: Assume we don’t know when the work item is entered and remove it from the metrics.
Pacemkr has taken option 2 in its calculation. It will not calculate a cycle time because it doesn’t know when the work item entered the workflow.
On the other hand, it knows when the work item is finished in the workflow. This means the throughput for this day will include work item A.
In other words, if you look at your cycle time scatter plot on Friday, you won’t see work item A because Pacemkr cannot calculate its cycle time. Looking at the throughput run chart, you will see work item A because Pacemkr knows when work item A finished in the selected workflow.
Removing a column from the middle of the workflow
Sometimes, it can be valuable to remove a column in the middle of the workflow. In our initial workflow, we could decide to remove the ‘Building’ column because it is an external step of your organization or outside your department.
Using the grid notation, let’s look at a work item that passed through every column of this workflow. In the following image, the cycle time is 5 days (Friday – Monday + 1). The work item spent 1 day in every column of the workflow.
By removing the ‘Building’ column in this workflow, we now have this grid notation:
Our cycle time is still 5 days. The work item started on Monday and finished on Friday.
What happens to the time spent in column Building? Where is this missing day going? It spent a day in all selected columns. But there’s a missing day in ‘Building’ that is left in the middle of nowhere.
Pacemkr cannot determine if the removal of a column is related to an external organization or department. It can only assume and do calculations with the data it has.
From Pacemkr’s point of view, the work item spent 2 days in the ‘Discovery’ column. As the ‘Building’ column doesn’t exist when it is removed from the workflow, its grid notation looks like this:
The cycle time is still 5 days (Friday – Monday + 1). The difference with the entire workflow being selected is that the work item spent 2 days in column ‘Discovery’.
Understanding where the work item starts in the workflow
If we go back to the definition of cycle time based on the Kanban Guide, it says:
Cycle time: The amount of elapsed time between when a work item started and when a work item finished.
Kanbanguides.org
This means the work item can enter any stage of the workflow to start its cycle time. It doesn’t have to enter in the first column. Consider the grid notation of this work item:
This work item entered the workflow on Monday in column ‘Building’. It then went backward in ‘Discovery’ and ‘To do’ on Tuesday before moving forward again to ‘Discovery’ on Wednesday.
Things can get complicated with these types of work items when a subset of columns is selected. Unfortunately, these work items are not always the exception. In some organizations, they are more the norm than the exception.
By selecting a subset of columns, it can have an impact on the metrics calculated by Pacemkr.
Here are a few situations based on the example above.
From ‘Building’ to ‘Done’
In this example, we select columns ‘Building’, ‘Validation’, and ‘Done’.
As the work item entered the workflow on Monday in the ‘Building’ column, it has the following components:
- Cycle time is 5 days: Friday – Monday + 1
- Out of workflow time: 1 day. On Tuesday, it was outside the workflow. Since it came back on Wednesday, we count Wednesday day as being in the workflow
From ‘Validation’ to ‘Done’
In this example, columns ‘Validation’ and ‘Done’ are the only columns selected.
The work item started in this workflow on Thursday and exited on Friday. It has a cycle time of two days (Friday – Thursday + 1).
From ‘To do’ to ‘Building’
In this last example, columns ‘To do’, ‘Discovery’, and ‘Building’ are selected.
Now this is a more difficult situation. The ‘Building’ column is our column when the work item finishes. It got in this column first.
The way Pacemkr looks at it is that the work item entered the workflow on Tuesday in the ‘Discovery’ column. It went backward in ‘To Do’, moved back into ‘Discovery’, and exited in ‘Building’ on Wednesday.
For Pacemkr, this work item has a cycle time of 2 days (Wednesday – Tuesday + 1).
Understanding where the work item ends in the workflow
While the Kanban Guide mentions a lot of times when a work item finishes, it doesn’t provide a lot of guidance on the definition of ‘finished’.
Pacemkr defined finished in the tutorial States and directions of work items.
A finished work item will be defined as:
A work item that left the workflow for the last time. Leaving the workflow means it has reached or went past the last column of the workflow and never comes back in the workflow.
Here are a few examples illustrating how this definition can affect your metrics.
Work item finishes at the end of the workflow
In its simplest form, a work item is finished on the last column of its workflow. In the following grid notation, the work item finished on Friday in the ‘Done’ column. As we’ve seen earlier, its cycle time is 5 days (Friday – Monday + 1).
Work item finishes after the end of the workflow
Sometimes, the work item doesn’t exit on the last column. In the following example, the work item exited the workflow on Friday. It just didn’t go through the ‘Done’ column. It went in a downstream column, ‘Monitor’, which doesn’t belong to the workflow.
For Pacemkr, the cycle time is 5 days. According to the definition of ‘Finished’ above, it left the workflow on Friday.
Work item finishes and comes back in
In the following example, the work item finished on Wednesday then moved back into the workflow on Thursday, and finished for a second time in ‘Done’ on Friday.
As the work item came back in the workflow on Thursday, it wasn’t finished until Friday. For Pacemkr, the cycle time of the work item is 5 days. The last time it left the workflow was on Friday.
Finishes but never comes back in
This last example explains how Pacemkr calculates a cycle time when the work item finishes on Wednesday on the ‘Building’ column. It then moved to ‘Validation’ on Thursday but since this part of the workflow wasn’t selected, the work item never came back in the workflow.
For this reason, the cycle time of this work item is 3 days (Wednesday – Monday + 1).
To sum it up
This section is intended to educate the reader on how Pacemkr handles different scenarios to calculate the cycle time of its work items. While the management of a board provides a lot of flexibility to its users, it can become difficult to understand its metrics when we allow so much flexibility with the movement of work items.
As you get a deeper understanding of the metrics calculated by Pacemkr, you can explain to your peers why numbers change when selecting a subset of your workflow.
In the next section, we will focus on the age of active work items. While less extensive than finished work items, active work items have some particularities worth mentioning for your benefit.
Age
Like the cycle time, the age of work items gets impacted based on the columns selected on your workflow in Pacemkr.
The following sections cover topics to help you understand why your metrics change when you select a subset of your workflow.
Active becoming finished work items
The first topic to understand when a subset of the workflow is selected is how some active work items become finished work items.
To illustrate this concept, let’s consider our workflow with work items A and B. Work item A finished today while work item B is active in column ‘Building’.
Let’s say you filter your workflow to only the first three columns. It now looks like this.
Work item A is now outside the workflow. Work item B is now in the last column of the selected workflow. It transformed from an active work item to a completed work item.
Usually, selecting a subset of columns in your workflow will give smaller cycle times and a smaller Service Level Expectation (SLE). Not always but it should be the most expected result.
Out-of-workflow time
In the tutorial States and directions of work items, we gave the following definitions:
Out-of-workflow: A work item is considered out of the workflow when it is in a column before the starting point or after the end of the workflow.
Out-of-workflow time: Time spent before or after the workflow.
States and directions of work items
Before the first column
Let’s consider an active work item moving in our workflow using the grid notation. It entered the workflow on Monday in the ‘Discovery’ column. It is now in the ‘Building’ column. We are on Thursday. It has an age of 4 days (Thursday – Monday + 1).
We can detail its movement in the following way:
- It spent 1 day in column ‘Discovery’
- It spent 1 day in column ‘To do’
- It spent another 1 day in column Discovery’
- It is currently in the ‘Building’ column
Our user removes the ‘To do’ column from the workflow. The new workflow using the grid notation is the following image:
The age of our work item is still 4 days. It got in the workflow on Monday and today is Thursday. But while it spent 1 day in ‘To do’ in the previous example, Pacemkr now says it spent 1 day out of the workflow.
We can detail its movement in the following way:
- It spent 1 day in column ‘Discovery’
- It spent 1 day out of the workflow
- It spent another 1 day in column ‘Discovery’
- It is currently in the ‘Building’ column
On or after the last column
Consider the work item that was finished on Wednesday in the ‘Done’ column but moved back to ‘Validation’ on Thursday. As we are Thursday, this is an active work item.
We can detail its movement in the following way:
- It spent 1 day in column To do’
- It spent another 1 day in column ‘Building’
- It was finished on Wednesday
- It moved back to ‘Validation’ on Thursday and is currently in the ‘Building’ column
Its age is 4 days (Thursday – Monday + 1). It spent 1 day in ‘To do’, 1 day in ‘Building’ and 1 day (or today) in ‘Validation’. The missing day, Wednesday, is considered out of workflow time in Pacemkr.
Conclusion
This tutorial aimed to educate the reader on the potential variations of metrics in Pacemkr when stages are excluded from the workflow. Depending on the location of the stages you exclude, it can change your metrics.
Before assuming Pacemkr is broken or miscalculated something, it is important to remember all the specific cases named in this tutorial and their impact on the metrics you are tracking.
English 
French