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 then 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 that is currently there were not accumulated on said workflow but on the initial workflow, the card was created and was moved through. Regardless of where the time was accumulated, it will be attributed to the workflow and board that the card currently resides in.
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.
Moving cards back and forth on the workflow
In general, cards in Kanbanize 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 in turn 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 takes the cards' accumulated cycle time into consideration, moving cards back and forth might cause cards to have a different end date visualized on a given chart, compared to the card's actual last date moved to Done.
Let's take the following example:
Actual entry date | Column | Analytics date | Cycle time |
01.01.2000 | Requested | 01.01.2000 | 2 days |
03.01.2000 | In Progress | 03.01.2000 | 2 days |
05.01.2000 | Done | 05.01.2000 | - |
07.01.2000 | In Progress | - | 2 days |
09.01.2000 | Done | - | - |
The card from the table above was created on 01.01.2000, it stayed in the Requested column for 2 days before it was moved to In Progress on 03.01.2000.
It stayed In Progress for another 2 days, after which it was moved to Done on 05.01.2000.
The card was then moved back from Done to In Progress and stayed there for another 2 days before it was again moved to Done on 09.01.2000.
Even though the card's actual end date is 09.01.2000, for the Analytics module, the end date of that card is 05.01.2000 as this is the first date on which it was moved to Done.
That being said, the Analytics module still takes into consideration the additional 2 days that this card spent In Progress (from 07.01 to 09.01), so if we assume that the Requested and In Progress columns participate in the cycle time calculation for the board, this card's total cycle time is 6 days (2 days in Requested and 4 days In Progress).
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, in turn, result in a predictable process and stable flow.