How does Jira calculate flow metrics and cycle time?

Justin Princehorn

I have googled/researched all over the web for help on how does Jira cycle time metrics (days in status) get calculated when cards get moved backwards in the flow? Typically, I hear from other coaches and articles that moving cards right to left generally is not a good practice because it can skew your flow metrics. I’m curious when it comes to Jira cloud tool, how does it calculate that type of stuff when cards are moving left to right, then right to left, then again left to right. I’m guessing some tools are better at it then others. Wondering how big of a deal it is on messing up Jira metrics when things moves backwards.

The reason I would love to know this is it will help me know how hard I should coach against moving cards from right to left. Some teams do it more than others and I really want to know the true impact of it.

Here’s an example to explain it my question….

Let’s assume the team’s workflow is  - To Do à In Progress à In Review à  Done

 Prior to Day 1 Card has been in To Do for 10 days already

 Day 1 – Card moves from To Do à In Progress

Day 2 – Card stays In Progress

Day 3 – Card stays In Progress

Day 4 – Card stays In Progress

Day 5 – Card moves from In Progress à In Review

Day 6 – Card stays In Review

Day 7 – Card moves backwards from In Review à In Progress

Day 8 – Card moves from In Progress à In Review

Day 9 – Card moves from In Review à To Do

Days 10-15 (6 days)  – Card sits in To Do

Day 16 – Card moves from To Do à In Progress

Day 17 – Card stays In Progress

Day 18 – Card moves from In Progress à In Review

Day 19 – Card moves from In Review à Done

 

So based on that the card would have sat in each state as follows:

 

To Do = 17 days total (10 days originally BEFORE work even started + 7 days after it moved back)

In Progress = 7 days total (4 originally + 1 day after it moved back + 2 days again later in the cycle)

In Review = 4 total days (2 days originally + 1 day after it moved back + 1 day again later in the cycle)

Done = 1 day

 

From this example, you conclude the cycle time for this card (the amount of days it took the team to do the work from the first day they pulled it in until the day they finished it) is = 12 days total

 

However, its my understanding that different agile tools may interpret / calculate flow metrics differently.

 

Tool 1 might look at it this way:

Overall time to deliver from the first day it moved to In Progress to Done (INCLUDING the 7 days it sat in To Do during days 9-15) and say cycle time = 19 days

 

Tool 2 might look at it this way:

Overall time to deliver from the first day it moved to In Progress to Done (EXCLUDING the 7 days it sat in To Do during days 9-15) and say cycle time = 12 days

 

Tool 3 might look at it this way:

Because the card moved back to To Do on day 9, the clock was reset to zero. Then clock starts again day 16 when moves to In Progress and say cycle time = 3 days

Bill Sheboy

Hi @Justin Princehorn 

Let's start with what the documentation says about the Days in Column setting: https://support.atlassian.com/jira-software-cloud/docs/customize-cards/#Using-Days-in-column

Note that if you move an issue back to a column where it's previously been, the indicator gives you the cumulative number of days the issue has stayed in that column.

For example, you move an issue to the 'In Progress' column, and it stays there for 2 days. You then move the issue to the 'Code Review' column, and it stays there for 1 day. During code review, you receive feedback, which requires more development work for the issue. So, you move the issue back to the 'In Progress' column, and it stays there for 1 day. In this example, the indicator reflects the cumulative value of 3 days for the issue in the 'In Progress' column.

Thus Jira uses the simple approach: sum up all of the days for time in any status mapped to that column.  Jira does not account for non-working days configured in the system with Days in Column, so that must be accounted for. 

IMHO, any tool which does not measure duration from start of work until completion seems not to be providing teams with an honest view of what happened.  (Imagine you used a physical Kanban board with sticky notes; would you game the cycle time to reduce the number?)

 

Regardless of tooling, another way to look at this symptom is what were the impact and reasons for backward flow, and discuss them at the team retrospective to learn and consider how to improve...

• Why did an item move backward, and was that expected by the team, such as for rework for a defect?  If so, backward flow just adds to cycle time, and so a discussion topic could be how to reduce rework.
• A more surprising thing you described was to move from an "in progress" to a "not started" status category.  That may indicate churn on item readiness for build, an abandoned item that wasn't abandoned, "WIP debt", etc.  Definitely worth a team conversation to learn.
• and so on.

 

Kind regards,
Bill