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
  • Issue status
  • Cycle time
  • Incomplete cycle times
  • Undefined cycle times
  • Off-hours handling
  • Lifetime
  • Active days
  • Flow efficiency
  • Flow efficiency excludes weekends

Was this helpful?

  1. Metrics & definitions
  2. Issue cycle time

Defining issue lifecycle and cycle time

Issues progress through various stages of completeness during their lifetime. Swarmia automatically calculates key properties and metrics for each issue.

PreviousIssue cycle timeNextDeveloper effort (FTEs)

Last updated 1 month ago

Was this helpful?

Issue status

Every team has slightly different conventions for how they use their issue tracker. Swarmia allows you to smooth out these differences through the so that every issue always has one of the following statuses: To Do, In Progress, or Done / Won't Do. This helps make the status of work comparable across different teams in the same organization.

The progression of issues through these statuses may not always be linear - someone might start working on a bug, only to realize they're out of their depth, and leave it for someone else. In this case, the status of the issue might've gone from To Do to In Progress, and then back again to To Do.

Cycle time

The cycle time of any work is the amount of time it has spent in the In Progress status, according to your issue tracker.

Most often, this is simply the time between starting the work (status becomes In Progress) and finishing it (status becomes Done).

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

You can see when each issue went into and out of the In Progress status from the Issue Activity Popup (accessible by clicking on any issue key found on Swarmia).

Incomplete cycle times

Swarmia also calculates incomplete cycle times for issues that are not yet Done. Such incomplete cycle times are clearly indicated in the UI and don't contribute to aggregate metrics such as your team's average cycle time.

Undefined cycle times

If an issue moves directly from To Do to Done status, its cycle time is not defined. This may happen when someone completed their entire work on an issue without ever updating the issue tracker, and the status of the issue is later corrected.

Such undefined cycle times do not reflect reality, and also do not contribute to aggregate metrics such as your team's average cycle time.

Off-hours handling

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.

This may seem unintuitive, or even unfair at first, but consider the following:

  • Many teams are distributed, and work may happen at various time zones

  • Even co-located teams have members with different work habits: someone shows up at 7 AM, someone squeezes in a bit of work time after 9 PM after putting the kids to bed

  • Different countries have different national holidays

  • Teams have off-sites and trainings which are not holidays, but not regular work time either

Attempting to take all of this into account would result in a number that's too complex to understand, not comparable across teams.

Lifetime

The lifetime of an issue is the amount of time between its first and last activity, according to merged data from your issue tracker and your version control system.

Issue activity includes all events that can be tied to the issue in question, such as commits, pull requests, and reviews. Issue status changes also count as activity.

For some issues, the lifetime will be the same as the cycle time: even if there's a lot of activity in between, the first activity will be the status change to In Progress, and the last activity will be the status change to Done.

But for many issues this is not the case: someone might have worked on the issue for days, before remembering to update the issue status to In Progress. Similarly, it's not uncommon to mark an issue as Done, only to spend the following days fixing all the little things you notice only in production.

The issue lifetime takes these realities into account. In contrast to the issue cycle time, it is often closer to the actual time it took to complete an issue from start to end.

On the other hand, the issue lifetime doesn't account for more complex issue status histories. For example, if you work on an issue for 1 week, take a 3-month break, and then finish the work in 1 week, the issue lifetime will be 3½ months. This is the case even if the issue was moved out of the In Progress status for the 3-month break.

Active days

The active days of an issue is the number of days on which it had some linked activity indicating the issue is moving forward.

Version control activity includes all events that can be tied to the issue in question, such as commits, pull requests, and reviews which count towards the issue active time. In addition to version control activity, completed child issues also count as issue active time.

For some issues, the active days will be the same as the lifetime: someone was actively working on the code each day while the issue was in progress.

But often this is not the case: teams might run into blockers, or be working on too many things at the same time. This will cause them to have days (or even weeks) when there's no active work being done towards completing the issue. The issue active days captures this information.

Flow efficiency

This number helps you quantify focus: for a focused team, making steady progress towards completing the issue, the number will be close to 100%. On the other hand, for a team that is trying to complete too many work items at the same time, the number will be significantly lower. Increasing your flow efficiency helps you deliver value earlier, and eliminate waste.

Flow efficiency excludes weekends

For the same reason, an issue may actually have a flow efficiency greater than 100%.

This special handling of off-hours is so that you have an intuitive target to aim for: less than 100%, and your focus may be spread too thin; more than 100%, and your pace might not be sustainable.

Same as with cycle time, there is .

You can see which days had activity in the .

As with cycle time, Swarmia has : if there is activity on weekends, it also contributes toward the active days of the issue.

The flow efficiency of an issue is the percentage of days when the issue was , compared to its whole .

, the flow efficiency takes weekends into account. That is, if your issue lifetime is from Monday to the Friday of the next week, and there is version control activity on each weekday, the flow efficiency of the issue will be 100%, even if there is a weekend in between.

Issue Activity Popup
no special handling of off-hours
no special for handling off-hours
actively worked on
lifetime
In contrast to cycle time
status mapping configuration
The activity pane shows when an issue transferred into in progress with the "Start" and "End" labels.