How to Calculate Cycle Time in Jira in 5 Steps
Key Takeaways
- Native Tools: Jira relies on the Control Chart to natively calculate cycle time, lacking a dedicated, out-of-the-box cycle time report.
- Status Mapping is Critical: You must manually select which workflow statuses count as "active work" to get an accurate cycle time calculation.
- The Weekend Flaw: Native Jira includes non-working days and weekends by default, which artificially inflates your cycle time metrics.
- The Average Trap: Jira’s default reporting heavily emphasizes rolling averages, which often masks the dangerous outliers stalling your sprints.
- True vs. Default: "True" cycle time only measures active execution, while default Jira settings often blur the lines with lead time.
As an Agile coach who configures Control Charts in live enterprise Jira instances daily, I constantly see teams struggling with workflow predictability. The uncomfortable truth is that native Jira does not make flow metrics highly intuitive, but tracking your actual delivery speed remains non-negotiable.
Before you can optimize your system, you must establish an empirical baseline. If you want to understand how these metrics fit into a broader reporting strategy, I highly recommend exploring our comprehensive guide on Jira cycle time and flow metrics reporting.
However, this specific tutorial strips away the theory. We are focusing purely on the mechanics of calculating cycle time natively in Jira, exposing exactly what the system hides along the way.
What is "True" Cycle Time vs Jira's Default?
Before clicking through Jira's reporting tabs, you must define what you are actually measuring. "True" cycle time is a strict measurement of active execution.
It begins the exact second a developer transitions a ticket from "To Do" to "In Progress." It ends the moment that ticket reaches a "Done" or "Resolved" state.
Jira's default reporting often confuses teams because the baseline configuration might encompass the entire lifecycle of a ticket. This is a primary reason why many teams ask why their Jira cycle time is inaccurate.
If your Jira board maps your "Selected for Development" status to the in-progress column, your cycle time will include all the days a ticket sat idle waiting for a developer. To achieve an accurate baseline, you must rigorously separate your active working statuses from your queuing statuses.
Understanding these foundational mechanics is crucial, and you can dive deeper into the overarching theory in our overarching Agile metrics and forecasting guide.
5 Steps to Calculate Cycle Time Using the Jira Control Chart
Jira does not offer a standalone button labeled "Cycle Time." Instead, it houses this data within a scatterplot. Here is how to configure it correctly.
Step 1: Locate the Control Chart
To find the Control Chart in Jira, navigate to your specific project board. Click on the "Reports" icon located in the left-hand sidebar.
Scroll down to the "Agile Reports" section. Click on "Control Chart." This will generate a default, highly cluttered scatterplot of your recent issue data.
Step 2: Define Your Timeframe and Filters
By default, Jira pulls in data from the last few weeks or months. You must restrict this to a meaningful timeframe, such as your last three sprints.
Use the "Timeframe" dropdown at the top of the chart to select a custom date range. Next, utilize the "Quick Filters" to exclude epics, sub-tasks, or specific issue types that do not represent standard delivery items.
Step 3: Map the Active Workflow Statuses
This is the most critical step for accuracy. Jira calculates cycle time based on the statuses you tell it to track.
Look at the "Columns" section at the bottom of the Control Chart configuration panel. Deselect all statuses that represent wait times or backlog queues (e.g., "Open," "Backlog," "To Do").
Only select active execution statuses (e.g., "In Progress," "In Code Review," "In QA").
Step 4: Address the Non-Working Days Limitation
Many Scrum Masters want to know how to exclude weekends and non-working days. Natively, Jira’s Control Chart does not allow you to easily subtract weekends from the cycle time calculation.
The native chart measures absolute elapsed time. You must manually account for this inflation when presenting data to stakeholders, which is a significant limitation of the tool.
Step 5: Read the Chart and Beware the Average
Once configured, the green dots represent individual issues. The y-axis shows the elapsed time in days. A blue line will track through the middle of the dots.
This blue line is the rolling average. As a practitioner, I advise you not to rely solely on this average, as it hides the extreme outliers that actually threaten your predictability.
Moving Beyond the Native Baseline
Can you calculate cycle time without an app? Yes, by following the steps above. However, the native Control Chart is notoriously difficult to read and completely lacks the ability to filter out weekends or generate percentile-based histograms.
Once you hit the ceiling of what native Jira can do, you will need to extend your instance. When native reporting falls short, you should evaluate the best Jira apps for cycle time and flow metrics to unlock enterprise-grade forecasting.
Tracking the data is only the beginning. The real value comes when you use these insights to coach your teams, identify bottlenecks, and dramatically improve your delivery speed.
Ready to stop facilitating and start forecasting? Master the flow metrics that guarantee predictability and upskill your career. Enroll in our AI for Scrum Masters training today.
Frequently Asked Questions (FAQ)
How do I find the Control Chart in Jira?
Navigate to your specific project board in Jira. Click on the 'Reports' tab located in the left-hand navigation menu. Scroll through the available Agile reports and select the 'Control Chart' to view your scatterplot data and begin measuring your team's workflow efficiency over recent sprints.
How does Jira calculate cycle time?
Jira calculates cycle time by measuring the total elapsed time an issue spends in specific workflow statuses. It starts a timer when an issue enters a selected active column and stops when it transitions out, plotting the resulting duration in days on the native Control Chart scatterplot.
Which workflow statuses count toward cycle time?
Only active execution statuses should count toward cycle time. You must manually configure the Control Chart to track specific statuses like 'In Progress,' 'In Review,' and 'Testing,' while explicitly excluding waiting or queue statuses such as 'To Do,' 'Backlog,' or 'Selected for Development'.
What is "true" cycle time vs Jira's default?
"True" cycle time accurately measures only the specific period where work is actively being performed by developers. Jira’s default settings often group lead time and queue time together, artificially inflating the final metric until you properly filter the columns to exclude idle waiting periods.
How do I exclude weekends/non-working days?
Native Jira does not offer a straightforward toggle to exclude weekends or non-working days from the Control Chart. The system calculates absolute elapsed time by default, meaning you must either adjust your team's expectations manually or integrate a specialized third-party marketplace app for accurate calendar filtering.
Why is my Jira cycle time inaccurate?
Inaccuracies usually stem from poor workflow mapping and lazy status updates. If issues sit in an 'In Progress' status while actually blocked, or if developers consistently forget to transition tickets in real-time, the resulting cycle time data will be fundamentally flawed and practically useless for forecasting.
Control Chart vs Cycle Time report - which should I use?
Use the Control Chart if you only have access to native Jira, as it is the default tool provided. However, a dedicated cycle time report generated via a marketplace app is vastly superior, offering clearer percentile distributions, histograms, and the crucial ability to exclude weekends automatically.
Can I calculate cycle time without an app?
Yes, you can calculate a basic cycle time baseline using Jira's native Control Chart. By carefully selecting your active working columns and strictly filtering your timeframes, you can track elapsed execution time without paying for any additional marketplace software or third-party reporting tools.
What's a good cycle time benchmark for a Scrum team?
A 'good' cycle time benchmark varies entirely by corporate context and work item size. However, high-performing Scrum teams generally aim to complete standard user stories within three to five active working days to ensure a highly predictable and steady flow of value delivery to customers.
How often should I review cycle time?
You should review cycle time metrics continuously throughout the sprint. Scrum Masters must monitor aging items daily during the Daily Scrum, and the entire team should analyze the aggregated cycle time data during every Sprint Retrospective to identify workflow bottlenecks and implement process improvements.