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
  • Prerequisites & Setup
  • Using Swarmia
  • Taking action
  • Roll-out strategy
  • Further reading

Was this helpful?

Improve your team's focus

PreviousAnalyzing pull request batch sizeNextOptimizing issue cycle time

Last updated 1 month ago

Was this helpful?

Engineering teams have a big responsibility of balancing multiple priorities. They have roadmap commitments, production incidents, internal improvements, and other types of work competing for their attention.

Many teams end up choosing priorities accidentally since, historically, there was no feedback loop. Common issues include:

  • Multi-tasking too much

  • Developers have their preferred types of work without aligning with the team's needs

  • Changing priorities when the previous project is 90% done

These issues weaken the team’s ability to deliver stories and epics. A great team finishes what they start.

Prerequisites & Setup

Using Swarmia

To get a sense of your team’s ability to deliver stories and epics, start from issue insights:

Every team splits work differently, so there’s no universal rule for issue cycle times. Ask yourself: Does this cycle time allow us to reflect regularly and course-correct?

It’s common to have rules like “epics shouldn’t take more than 1-3 months and stories shouldn’t take more than 1-2 weeks.” This makes sense because a common failure pattern is to start a project based on false assumptions and then keep grinding with no end in sight.

In focus summary, you can analyze how much effort each team spends across all projects:

Another way to look at your long-term ability to deliver is by using high-level work log.

If you consider this from your customer’s perspective (”How often am I getting some valuable updates in the product?”), the team on the left delivers new increments every week. The team on the right has many things in progress, but they might not have anything to release in a long time.

To really address the issue, you’ll need to zoom in. This requires an understanding of the work itself, so it’s best done by the team itself. This is a very common discussion in a team retrospective.

Work log shows the last two weeks of work at the detailed level. You can identify patterns like:

  • Days with no activity: did we shift our focus to one of the other lanes, or did we hit a blocker?

  • Solo work: if only one person works on a feature, it’s more difficult to get proper code reviews done, and the work progresses more slowly.

  • High levels of reactive work: while taking ownership of the codebase is important, sometimes this signals too broad a scope for the team or a lack of clarity with the feature work.

  • Complex sub-tasks: did one of the sub-tasks take so long that the whole project got delayed?

On each page, you can select an individual issue to analyze it in more detail:

Taking action

Setting a Work In Progress (WIP) limit is often considered the most important process improvement. This practice, which originated from Lean and Kanban, is well-researched.

The logic is that when the team has limited “slots” of work they can take, they are forced to make decisions. If something is blocking our work, we must unblock it rather than work on something else. Similarly, teams will be able to better manage external stakeholders, when they can let them know they can’t pick up additional work just yet.

In Swarmia, you can create WIP limits for different types of work as Working Agreements:

  • Limit work in progress to 2 stories

  • Limit work in progress to 1 epic

  • Limit work in progress to 10 pull requests

In addition to the WIP limits, you can have other related Working Agreements:

  • Avoid working alone on stories/epics

  • Close stories in less than 14 days

Once you’ve decided how you want to work, the most important thing is to follow through. Agree with your team to start every retrospective by looking at Swarmia data together. This allows you to ground the discussions in facts and often surfaces new perspectives.

Roll-out strategy

  1. Select a handful of teams for a pilot and coordinate with their team lead. Make sure that the setup is done correctly.

  2. Have leadership go through the issue cycle times for different teams to see where we currently are.

  3. Facilitate a retrospective with each team. Come up with a prepared list of potential root causes, but be open to the experiences the team can bring.

  4. After seeing some changes with one of the teams, use that as a case study when rolling out Swarmia to a broader set of teams. This allows you to speak using your organization’s language, rather than discussing productivity in a more generic sense.

Further reading

Swarmia uses data from your issue tracker to understand which projects you’re working on: configure the or the .

Your team will need to using one of the supported mechanisms.

Model for in Swarmia

Jira integration
Linear integration
link pull requests to issues
measuring engineering effort
High-level work log
Healthy staircase pattern vs. scattered activity. On the left you can see a team that works on one thing at the time, and then moves on to the next one. On the right you can see a team that starts a lot of projects, but doesn’t finish them.
Work log grouped by issue
Issue overview
WIP limit working agreement