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
  • Why should you care about issue cycle time?
  • Defining issue cycle time
  • Are you able to focus on the important things?
  • Analyze the flow of work
  • Introduce work in progress limits
  • Are you structuring work for success?
  • Work as a team
  • "But we're more effective when working alone!"
  • Minimize scope
  • Evaluate your planning skills

Was this helpful?

  1. Improve your team's focus

Optimizing issue cycle time

Practical tips and best practices for improving your focus and structuring work to reduce issue cycle times.

PreviousImprove your team's focusNextAnalyzing activity patterns on Work Log

Last updated 2 days ago

Was this helpful?

Why should you care about issue cycle time?

As the complexity of a software organization and codebase increases, the teams in the organization face new challenges. Teams find themselves in an environment of team and system dependencies, and an increasing number of problems competing for their attention, including legacy systems and technical debt.

If the teams keep on doing what they've been doing, their existing work structures (for example Epics, Stories and Tasks) end up taking much longer than what they used to. As a result, the teams become slower to deliver software to the end-users and to react to new knowledge or customer feedback.

To reverse this trend, teams need to start measuring cycle time with an aim to decrease it. Retrospectives and working agreements are both great tools for turning cycle time insights into systematic action, like limiting work in progress.

These actions should be accompanied by structuring and breaking down the work with a goal of optimizing for cycle time and team collaboration.

Defining issue cycle time

The cycle time of any software work is the amount of time from the start of development work until the end result reaches the customer. For issues, the most understandable way to measure this is to look at the time it stays In Progress, based on the issue tracker status. In practice, the time spent in progress can often be split into multiple steps (e.g. a separate step for any time that an issue spends in review) – in which case you want to look at the combined time spent in these statuses (refer to to configure this on Swarmia).

Since the progression of issues is not always linear, it is important to be able to differentiate between the time the issue has been actively worked on, and the time between the first and last activity on the issue. There are valid reasons for pausing work on an issue – perhaps there's a critical bug in production, or perhaps the team had to revisit some assumptions about the problem and redesign the solution – but it's important to know when this happening.

Swarmia automatically calculates key properties and metrics (such as , and ) for each issue to allow investigating how they went and what could have been done better.

Are you able to focus on the important things?

In software teams the issues that are visible in your project management software almost never tell the full story about what teams are actually working on. There are always other priorities taking time away from completing your planned roadmap work. It's not possible (nor wise) to eliminate distractions completely, but it's important to understand the effect of context switching on the cycle time of your high-priority items.

Analyze the flow of work

It can be easy to get lost in the sea of problems and day-to-day work, especially without a proper way to measure what kind of work a team is spending their time on.

Swarmia's Work Log view is a good place to start understanding the full breadth of work in progress. You'll also get a view on work you think is in progress but doesn't have any real activity in a separate section.

Clicking on any issue to open the activity popup will reveal its flow efficiency – a lean metric telling you the proportion of days you have actively worked on the issue during its lifetime. If the issue has low flow efficiency and you did not work on it the whole time this often indicates having too much work in progress simultaneously. This symptom is also visualized on the work log as an absence of regular day-to-day activity on stories in progress.

Introduce work in progress limits

If it looks like you are working on too many things at once, hindering the progress of your top priorities, consider adopting a working agreement limiting the work in progress. This way you'll stay on top of your work in progress and can act fast if you are drifting towards working on too many things at once. A good rule of thumb for the target number of stories in progress at once is Math.floor(number of devs / 2).

Are you structuring work for success?

When work slows down, the effect is usually most obvious with the larger units of work. When stories start to take up to a month and epics more than a few months, the team can usually feel that things start to feel slow. Decreasing cycle time at this level can have a significant impact not only on the team's velocity but also how rewarding and fluent the work feels. So how do you improve?

Work as a team

The first step is simple: plan your work for at least two developers. One could argue that how you split the work doesn't matter, because the same work is going to get done anyway. However, there are two main reasons why it does:

  • How you split your work affects collaboration. If your smallest increment of work takes 2 weeks from one developer, it means they are unlikely to collaborate with others over those two weeks. Developers sometimes prefer this due to fewer distractions, but the downside is that the team shares less information, ends up creating worse plans, and takes less interest in their teammates' work.

  • The completion of work marks a natural time for re-evaluating a plan. If the team works on a feature for several months, chances are that some new information is not applied in the plan. Since software is often built with a large amount of uncertainty, it's critical that teams are able to apply learning early and regularly.

There are many other benefits that the teams gain by structuring their work in a way that enables collaboration. For instance, this often leads in reduced time-to-market for new products or features, resulting in more engagement with the customers and ultimately a better product. The developers are happier when they're collaborating and getting better support (e.g. getting better code reviews from their peers working on the same topic).

"But we're more effective when working alone!"

When everyone is working on their own project, work might feel efficient due to not having to coordinate anything with others. However, building a great product and team is a long-term effort, and the benefits far outweigh the costs in the long run, for the team and developers alike.

  • Structuring work with developer collaboration in mind forces you to be more thorough in the planning process. This can helps clarify the context for the team and reduce unknowns before the implementation.

  • Tough problems become easier when you don't have to work on them alone. You're going to have an easier time sparring, rubber-ducking, and getting your code reviewed, all of which likely make your work flow better and reduce moments of frustration.

  • Too many competing priorities can lead developers and teams to work on simple, reactive tasks. These are easier to complete, but time spent on them might not maximize the impact of the team. It's often better to focus attention on properly solving few problems that really matter, rather than struggling to solve too many problems at once.

Minimize scope

When the work in progress seems to not hinder completing your projects and they still seem to take too long to complete, you may need to look elsewhere for solutions. Another typical challenge to overcome is that a team is trying to solve too large of a problem at once. This is why you should critically evaluate the total scope of the issues.

Evaluate your planning skills

There is much more to planning than just sheer scope of the issues. It is rare that upfront planning manages to account for all the tasks that end up going into an issue. This is why being aware of how the scope of the issue developed over time is important.

If you already know how much extra work you'll add on average (eg. 20% more tasks), you can take the scope creep into account when starting to plan the issue (for our example, this might mean three more tasks to complete, taking two extra days). You can also learn about certain types of tasks that tend to be always added to the scope after starting, and gradually increase the quality of planning.

As a side effect, you'll also become better at estimating how long the work will take to complete (which might help when making prioritization calls, deciding what to communicate to a stakeholder, or serve as a hint to split the work in smaller increments).

It is also common that challenges with scoping extend to the sub-tasks of the issue. There are often a couple of outlier tasks that took longest to complete for some reason. Identifying long running tasks and thinking about if they could have been split somehow will also positively contribute to the quality of planning future issues.

You can set working agreement targets for the amount of issues in progress (eg. "No more than three stories in progress at once"). about working agreements.

You can measure and improve your ability to work as a team on issues with Swarmia. This can be done by adopting a for avoiding solo work. about working agreements.

For instance, a team might have structured the work in a way that would have created customer value and been able to learn more, before completing the whole original scope. The power of small stories to deliver more value for customers is well researched and there are to optimize your issue sizes.

Learn more
working agreement
Learn more
good strategies out there to slice your stories
these instructions
active time
lifetime
flow efficiency