Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1

The date associated with a workflow stage for any given work item is the last date the item entered each workflow step.

Detailed Information

If an item is moved backwards in the flow, say from step C to step B, it is considered never to have been in step C at all. All of the time in step C will be added to the time in step B. It will get a new timestamp for step C when it reenters that workflow stage.

Ex.) Say you got in the checkout line at the grocery store but then forgot something. Until you enter the line for the final time, the checkout line clock doesn’t start. Until then you were shopping, with a slight detour.

We really recommend the book “Actionable Agile Metrics for Predictability” by Daniel Vacanti. There is a whole section on this!

For those expecting to see a cumulative total of all days spent for an item in any given stage in the Cycle Time charts, you might be very confused as to why we do it this way. This is intentional as the app is designed for helping facilitate the flow of work through the process as smoothly as possible.

The Logic Behind It

In flow-based systems, we attempt to optimize the journey of the work through your system. Visibility into what happens in each stage is very important to this goal. In a board, when you move a card backward, say from Testing back to In Progress, you lose all visibility that a card was in the Testing state before. It is a statement that it was a false start, it wasn’t ready for that stage so it went backwards.

If that isn’t the intent of the backwards motion, there are other approaches to workflow building and board visualization that could be considered that don’t have the negative effect of blocking visibility as discussed above. One is often is to re-think the definitions of the workflow stages.

A lot of times we think of an In Progress stage as the domain or inbox of a particular role, say a software developer, and Test as the domain or inbox for someone else, like a QA analyst. Instead, you can consider the “Test” workflow stage to contain both the Test work and all resulting changes. Obviously you’d like for there to be minimal or non-existent work after testing. Keeping an item in Test for the duration of all of this activity really highlights how long it has been since Testing first began and can cause discussions about how to decrease time since Test started (which obviously can vary wildly). It may also make people more cautious about moving forward, which can be a good thing.

Did you know?

The way we treat backwards movement is actually what allows a Cumulative Flow Diagram to display properly. Lines on a cumulative flow diagram should never go down.

55 Degrees offers another app called Issue Analyzer for Jira Cloud that can extract all of your timestamp data for your Jira issues among other things. It can show you first entered, last entered for each state. Please note that this isn’t a flow-based metrics app, this is about finding detailed information about issues.

  • No labels