Blog

Moving backwards

Moving cards backwards on your Kanban board

Almost all teams occasionally move a card backwards on their Kanban boards for one reason or another. Moving cards backwards isn’t always a bad thing but, backwards movement can have unintended consequences when you’re calculating flow metrics.

What happens to the data when cards move backwards?

Many people assume that all tools measure the Cycle Time for a workflow stage by adding up all the cumulative time an item spent there. Tools like ActionableAgile that focus on metrics for flow optimization do not! How work moves through the process impacts how we capture Cycle Time for the process and any state within. So, what do we do? Well, the answer is best seen in the Source Data chart. It is the place where you can find all of the dates we’ve captured for an item’s travels through the workflow.

ActionableAgile always starts by capturing the date when a work item first moves into a column (or a workflow status mapped to a workflow stage if you’re in Jira and not using a board.)

Source Data Chart entry for a work item that has moved forward through the entire workflow

In the image above, we can see that a work item with the ID of FLOW-10 began in To Do in November of 2018, was moved to In Progress in January of 2019, and moved through Release Ready into Deployed on the same day in July 2021.

But, those captured dates can get removed when cards move backwards in that process. If FLOW-10 were to move backwards from Deployed into Release Ready for whatever reason, we remove the date stamp for Deployed.

Source Data Chart entry for an item that has moved backwards from Deployed to Release Ready

If the item were to move from Deployed through Release Ready all the way back to In Progress, we would remove the date stamp for both Deployed and Release Ready.

Source Data Chart entry for an item that has moved backwards from Deployed to In Progress

Essentially, when you move a work item backwards, all of the time that it accumulated in the stage you’re moving it out of (and any stages that you’re moving it through) gets added to the time already spent in the destination workflow stage. So, in the image above, the data now shows that it has continuously been in In Progress since January 30, 2019.

When it finally moves through those stages again, the date they revisit the stages will be captured in the Source Data chart.

Source Data Chart entry for an item that re-enters Release Ready and Deployed after backwards movement

What does this mean for me and how I work?

First know that it is always ok to move a card backwards when it was a mistake to move it forward in the first place. Accidentally dragged the wrong work item to done? Just move it back to where it was accidentally moved from. Just make sure that you don’t move it back any farther or you’ll lose valuable data.

For example, if you have a card that accidentally moved from In Progress to Deployed, move it back to In Progress. If you move that card all the way back to To Do then dates for all subsequent columns will be removed and it will look like it never left To Do.

Once you understand how backwards movement affects your data, the inevitable question then becomes “Well, if I shouldn’t move cards backwards, what should I do instead?” The answer can be contextual but almost always lies in how you design and use your board. How you anticipate and plan for these activities as expected things rather than unexpected things can make a huge difference. We have a few key tips in a companion blog post on designing boards for flow. Take a look then contact us for any questions you might have!

Related Article