-
Bug
-
Resolution: Unresolved
-
Medium (View bug fix roadmap)
-
None
-
None
-
17
-
Severity 2 - Major
-
2
-
Summary
Using recursive transitions (from a given to status to itself) impact negatively Agile reports such as:
- the Control Chart
- the Cumulative flow diagram
Impact on the Control Chart
The Jira Control Chart doesn't handle recursive transitions (from a given to status to itself) correctly. It will only count the time spent in the first "cycle" on that status.
Steps to Reproduce
- Create a Scrum Project;
- Create a Sprint;
- Create an issue and put in in the Sprint then start the Sprint;
- Transition the issue from "To Do" to "In Progress";
- From "In Progress", wait a couple of minutes and then execute the transition to "In Progress";
- Wait another couple of minutes and execute the transition to "Done";
- Go to the board > Reports > Select Control Chart > Select All Columns
- Click on the issue on the chart and it will only show the cycle time for the first cycle in the "In Progress" status. For example:
Using Jira Suite Utilities, you can see the time for the second cycle in the "Transitions" panel.
Expected Results
The report should sum up "Cycle Time" for the two cycles in that status, or for as many cycles that might happen.
Actual Results
Cycle Time is only calculated for the first (edit: last) cycle in the status.
Notes
This is actually an expected behavior according to the Control Chart documentation:
[...]
Tip 3: Exclude current work
The Control Chart shows data for issues that have been in a selected column but are no longer in a selected column. This gives the cycle time (total elapsed time) for the issues. However, by default this will include issues which are still moving across the board.
[...]
Impact on the Cumulative Flow Diagram
The Cumulative Flow Diagram might show negative values, when using the Refine button to select a specific status.
Workaround
Do not transition issues to the same status.
- duplicates
-
JSWSERVER-11075 Kanban board cycle time not calculated correctly if issue transitioned in place
-
- Closed
-
- mentioned in
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
- was cloned as
-
SW-2306 Loading...
Form Name |
---|
I've seen this actually only count the cycle time from the last period in a column, not the first.
Example 1 - A ticket is In-Progress for a couple of weeks, the team member accidentally moves it to In-Progress again (because workflow is relaxed with All transitions to all statuses), and then transitions it forward (to Done or whatever the next column/status is) and the In-Progress time is represented as only 1m in the Control Chart!
Example 2 - A ticket needs to move back to In-Progress after it has spent time elsewhere. After it moves forward, the Control Chart appears to only take the latest time spent in In-Progress.
This negatively impacts averages and mis-represents cycle times.