Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

How to Deduct Flagged (Blocked) Time from Jira Cycle Time

Jira Time in Status for Blocked Time.jpgEvery team is unique, with its own workflows, structures, priorities, and specific custom fields that make Jira function effectively. When it comes to time tracking, there is no exception. While many teams follow Agile metrics like Cycle Time and Lead Time to measure efficiency, no two teams define that data in quite the same way.

Let me clarify what I mean: In a perfect world, an issue would move to a specific "Blocked" status the moment work stops. But in reality, most teams use Jira’s Flagged feature to signal impediments while the ticket stays in an active status like "In Progress." Moreover, standard Jira reports are often blind to this nuance. They see a ticket that has been "active" for two weeks, even if it spent 6 of those days waiting for an external or internal dependency, or a third-party approval.

This creates a business problem: Data Noise. When your Cycle Time and Lead Time are inflated by factors outside the team’s control, your metrics become misleading. You might conclude that your engineering team is slowing down when the real bottleneck is a broken procurement process or a resource dependency. Without the ability to isolate these flagged windows, you lose the objective evidence needed to fix the actual problem.

This is exactly why the ‘Any Field Duration’ report in Timepiece - Time in Status for Jira is irreplaceable for so many teams. It offers the freedom to track any custom or system field, going far beyond simple status transitions. This is vital because to understand the real picture of your team’s engineering efficiency, you need data that is 100% accurate.

Here is how you can use Timepiece to refine your metrics and achieve true data-driven transparency.


Step 1: Establish a Real-World Baseline (Custom Calendars)

Before you can calculate blocked time, you need to ensure you aren't counting weekends or holidays. A 24/7 clock skews data by suggesting work was happening when the team was actually offline.

Navigate to Settings > Apps > Timepiece > Calendar Settings.

Define a Custom Calendar that reflects your team's actual hours (e.g., Mon–Fri, 9:00 AM – 5:00 PM)

custom-calender-time-in-status (1).jpg

By excluding non-working hours, Timepiece ensures that any reported duration, including flagged time, is based only on active hours.

 

Step 2: Track the "Flagged" Field Duration

Standard Jira reports typically only track status transitions (e.g., moving from "In Progress" to "Done"). However, most impediments happen within a status. An issue might stay "In Progress" for 10 days but be flagged as blocked for 2 of them.

To capture this, use the Any Field Duration report. This scans the historical change logs of any custom or system field, in this case, the Flagged field, to see exactly how long it held a specific value.

 image-20260227-105910 (1).png

In the Report Type menu, select Any Field Duration. Then, add your active statuses (e.g., Implementation, Test, Analysis). These are the statuses whose duration will be included in the report.

Pro Tip: To calculate Cycle Time, add only your active statuses (like Implementation or Test). To see Lead Time, include waiting statuses like Backlog or Waiting for QA.

image-20260227-105854.png

Step 3: Configure the History Field


This is where the magic happens. By clicking the History Field button and selecting Flagged, Timepiece analyzes your issue history to separate the "Unflagged" time from the "Impediment" time.

 image-20260227-110026.png

Once you click ‘Apply', you’ll see two distinct columns:

(-): The total duration the issue was unflagged (your true Active Work Time).

Impediment: The total duration the issue spent in a flagged state.

image-20260302-104335.png


Step 4: Analyze Impediments Across Sprints

One of the biggest advantages of this granular view is the ability to include multiple fields in one calculation. By adding Sprint to your History Field along with Flagged, you can see exactly which tasks were the most problematic during a specific Sprint.

image-20260303-131135.png

This provides the objective data needed for retrospectives. Instead of saying "the sprint felt slow," you can show that "30% of our Cycle Time was lost to external blockers."

image (55) (1).png

Conclusion: Precision Over Guesswork

Agile excellence isn't about raw estimates; it’s about clarity. By isolating Blocked Time, you separate your team’s actual velocity from external and internal delays. This level of precision empowers you to eliminate hidden waste and build a predictably fast delivery system.

To learn more about Timepiece - Time in Status for Jira, you can visit its Atlassian Marketplace page.

0 comments

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events