LogoLogo
Book a demoLog in
  • Swarmia documentation
  • Getting started
    • Get started in 15 minutes
    • Integrations
      • GitHub
        • GitHub Enterprise Server
        • Multiple GitHub organizations
        • Forked repositories
        • Troubleshooting
          • Reinstalling the Swarmia GitHub app
          • Updating app permissions
          • Installing Swarmia outside of GitHub Marketplace
      • Jira
        • Jira Server and Jira Data Center
        • Multiple Jira organizations
      • Linear
        • Private Linear teams
        • Disconnect Linear
      • Slack
        • Private Slack channels
      • Authentication
        • Google Single Sign-On
          • Frequently asked questions
        • Okta Single Sign-On
      • HR systems
      • Data export
        • Data cloud
        • Export data as a CSV file
      • Other integrations
        • Other issue tracker integrations
        • Other source code hosting integrations
  • Configuration and data quality
    • Teams & members
      • Creating & managing teams
        • Teams API
      • Contributors
      • Roles and permissions
      • Inviting team members
    • Issue tracker configuration
      • Jira configuration
      • Jira best practices
      • Linear configuration
    • Pull request exclusions
    • Linking pull requests to issues
    • Investment categories
    • Deployments
      • Generate deployments from merged pull requests
      • Generate deployments from GitHub deployments
      • Generate deployments from GitHub checks
      • Generate deployments via the API
        • Generate deployments for monorepos via the API
    • Sprint configuration
  • Use cases
    • Improve pull request flow
      • Pull request insights
      • Reducing pull request cycle time
      • Review code faster
      • Managing pull requests in progress with the Pull Request view
      • Diagnosing low pull request throughput
      • Analyzing pull request batch size
  • Improve your team's focus
    • Optimizing issue cycle time
    • Analyzing activity patterns on Work Log
    • Grouping activity on the Work Log view
    • Focus summary
  • Balance engineering investments
    • Activity and effort-based models
    • Categorizing work
    • Common problems with balancing engineering investment
  • Deliver strategic initiatives
    • Forecasting initiatives
  • Capitalize software development costs
  • Run developer experience surveys
    • Creating a survey
    • Managing surveys
    • Viewing and sharing survey results
    • How we show your survey responses
    • Survey communication guide and templates
  • Track DORA metrics
    • Automatic change failure detection
    • How Swarmia links PRs to deployments
  • Coach software developers
  • Get visibility into your CI pipeline
  • Continuous improvement
    • Working agreements
  • Notifications
    • Team notifications
    • Personal notifications
  • Retrospectives with Swarmia
  • Metrics & definitions
    • Pull request cycle time
      • What's the difference between "Change lead time" and "Pull request cycle time" metrics in Swarmia?
    • Issue cycle time
      • Defining issue lifecycle and cycle time
    • Developer effort (FTEs)
  • DORA metrics
    • Change lead time
    • Deployment frequency
    • Mean time to recovery
    • Change failure rate
  • Throughput
  • Time to deploy
  • Batch size
  • Flow efficiency
  • Scope creep
  • Sprints
  • Frequently asked questions
    • How do you treat weekends in metrics?
    • Tracking squashed commits
    • How do merge queues affect my metrics?
    • Why is my commit not visible in Swarmia?
    • How do I account for people leaving my organization?
  • Resources
    • Security & data retention
      • Data security
      • Data access
      • Swarmia IP Addresses
      • Single Sign-On (SSO) / SAML
      • Can I get a copy of the SOC 2 Type II audit report?
      • Deleting your organization
  • Pricing & plans
    • Compare plans
    • Free plan
    • Do I need a credit card to start a free trial?
    • What are the differences between the individual modules and the standard plan?
    • How do you determine the number of developers for billing?
    • What happens to customers with the Lite plan after the December 2024 pricing and plan change?
  • Changelog
On this page
  • Summary
  • Example
  • Why it matters
  • How to use it
  • Where to find it

Was this helpful?

  1. Metrics & definitions

Issue cycle time

Issue cycle time is defined as the amount of time work has spent in the ‘in progress’ status, as defined by your issue tracker settings in Swarmia. This calculation is the same across all different is

PreviousWhat's the difference between "Change lead time" and "Pull request cycle time" metrics in Swarmia?NextDefining issue lifecycle and cycle time

Last updated 1 month ago

Was this helpful?

Summary

The average cycle time of an issue is calculated by taking all of the cycle times shown in the given time frame and providing the average.

Swarmia doesn't differentiate between work time and off-time in cycle time calculations. That is, weekends count as cycle time, as do non-business hours of the day.

Example

If a Jira story was moved to ‘in progress’ on a Monday and then moved to ‘done’ by Friday, it would have a cycle time of 5 days.

Let’s say there were 6 stories in the last 30 days with cycle times of 5 days, 4 days, 10 days, 2 days, 8 days, and 9 days. You would see an average cycle time of 6.3 days for that time period.

More complex status histories are also accounted for. For example, if you work on an issue for one week, but then your priorities change, and that work is postponed for three months. You then start working on it again and finish it after one week. With this history, the issue will have a cycle time of two weeks, not 3½ months, as long as the issue was moved out of the ‘in progress’ status for the three-month break.

Why it matters

The longer an issue is open, the more your cost of delay increases. Additionally, the longer an item is open, the more context is lost and the greater the risk of quality issues.

Faster cycle times ensure the work is broken down small enough to provide high quality and high value to the customer. A consistent cycle time makes predicting the delivery of work easier as well.

How to use it

High cycle times could indicate that the work needs to be broken down into smaller pieces. It could also indicate that there is some kind of bottleneck holding up your issues from completion that you might want to drill into further to understand. Once you have a predictable issue cycle time, it’s much easier to plan work and also spot outliers that you need to take action on.

Read this blog post for more concrete tips on .

Where to find it

You can find issue cycle time in several parts of Swarmia, wherever issues are mentioned.

tackling typical problems with issue cycle time