Moving Cards between Boards/Workflows
A common problem that arises when looking at metrics and analytics of cards that move between Workflows and Boards is confusing and/or incomplete metrics data that affects the accuracy of the analytics module for the given cards.
A common cause for this behavior is when a card has gone through the whole process on a workflow, has reached the Done column, and is then moved to the Requested column on another workflow (or to another board). The card retains all the metrics from the previous workflow (and board), and the time spent in custom columns will be counted towards the main sections of the workflow/board (Backlog/Requested/In Progress/Done/Ready to Archive). This means that metrics from the previous workflow are being attributed to the new workflow/board, even though they were not accumulated there. The initial workflow/board also lacks the metrics for this card, and it will not be visible on the analytics regarding it.
The analytics of the second workflow will be skewed because the metrics of the card currently there were not accumulated on said workflow but on the initial workflow, where the card was created and moved through. Regardless of where the time was accumulated, it will be attributed to the workflow and board in which the card currently resides. **
For this purpose, instead of moving the card from one workflow/board to another, you can create a 'Card is Moved' business rule, which can create a relative card (on another workflow or board) when the first card is moved to Done on the primary workflow/board. This will ensure that each card has its individual life cycle on the appropriate workflow/board.
Alternatively, you can copy the cards onto another workflow/board to trigger the same behavior.
Due to the above, frequent changes to the board/workflow's design may lead to such issues in the future, therefore, it is recommended that the users take the time to familiarize themselves with the types of workflows and carefully design their board layouts based on their process and scenarios.
** Let's illustrate that with an example.
The times displayed in the Analytics module are based on card transitions — the movement from one column to another. Let's take a look at the following card that was submitted by Mark to the Support team board:
1. The card has spent about 4 minutes in Requested and 2 hours In progress on the Support board. Then, it was moved to the Solution Architecture board, where it spent the remaining time and was located there when the screenshot below was taken.
2. A few minutes ago, we moved this card from the Done section of the Solution Architecture board to the Done section of the Support board and loaded the Cycle Time Scatterplot.
You can see how the times on “This board” and “Other boards” have changed their places because the screenshots were taken when the card was located on the different boards (the one directly above is taken after the card was moved back to the Support board)
Then, in the Scatterplot, we can see that the system displays the full 6 days the card has been in Requested and In Progress combined from both boards. If we were looking at the CFD, we would see those times removed from the CFD on the Solution Architecture board and added to the CFD on the Support board.
Moving Cards Back and Forth on the Workflow
In general, cards in Businessmap are intended to be moved from left to right through columns in each section of the workflow, i.e. from Backlog to Requested, from Requested to In Progress, and from In Progress to Done.
In some cases, cards might get moved back and forth on the workflow, e.g., from Done back to In Progress or Requested. However, this is not a recommended practice as it might skew the cards' metrics data, which could cause the analytics module to produce unexpected results when looking at the different charts.
Since the analytics module relies on cards' transitions along the workflow (entry and exit dates) for each column, and it considers the cards' accumulated cycle time, moving cards back and forth might cause cards to have a different start/end date visualized on a given chart, compared to the card's actual last date moved to Done.
In general:
- moving a card backward after it has reached the Done column will affect its end date
- moving a card backward before it has reached the Done column will affect its start date
This is how the analytics module calculates the end date:
Done = Creation date + total time spent in Backlog + total time spent in Requested + total time spent In Progress
Start date example
Let's take the following example for a start date:
You have a card that was created in the Backlog on date D1 and stayed in the Backlog for X days.
On 2023-08-04 (August 4th), it was moved from the Backlog to In Progress (actual start date).
On 2023-08-08, it was moved from In Progress back to the Backlog.
On 2023-08-14, it was moved from the Backlog to In Progress (+6 days in the Backlog → from 2023-08-08 to 2023-08-14).
Therefore, the total time spent in the Backlog for this card is X + 6 days.
For the Analytics module, the start date of the card is D1 + (X + 6) days, i.e.:
D1 + X days = 2023-08-04
04.08 + 6 days = 2023-08-10
End date example
Here's an example of an end date:
You have a card that was created on 2023-07-06 at 11:42:45 (UTC+2).
The card spent a total of 54 minutes and 47 seconds in Requested.
The card also spent a total of 11 days 21 hours 49 minutes 3 seconds in the In Progress column.
Therefore, the end date = 2023-07-18 at 10:26:35 (UTC+2)
Due to the above-described behavior, a best practice is to try and avoid a back-and-forth movement of cards to ensure that the metrics data visualized by the analytics module would be accurate, and this would result in a predictable process and stable flow.