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
  • What makes a good retrospective?
  • Before the retrospective
  • During the retrospective
  • After the retrospective

Was this helpful?

Retrospectives with Swarmia

How to run great retrospectives with Swarmia.

PreviousPersonal notificationsNextPull request cycle time

Last updated 14 days ago

Was this helpful?

What makes a good retrospective?

Swarmia is all about enabling data-driven continuous improvement cycle in software development teams. As the purpose of retrospectives is to facilitate continuous improvement in a team setting, using Swarmia in retrospectives can help you get there. Great retrospectives have three things in common, they are blameless, fact-based and actionable:

Blameless

One of the worst things to happen in retrospectives is that it becomes a blame game having an overall negative effect on team work. This is why it is important to keep a blameless mindset and focus on improving team dynamics in retrospectives. A long-running task is not someone's fault, but the result of the team organizing their work in a certain way.

Fact-based

Having a shared fact base when conducting retrospectives helps you identify objectively what went well and what we could still improve as a team. However, many teams are not used to full transparency of data. It can be useful to remind the team that looking at the data allows us to have a more directed conversation about things to improve. Looking at the data feels even less appealing if it seems to be incorrect. It's good to highlight the elements that contribute to the data quality: practices using the issue tracker, linking of Pull Requests to issues etc.

Actionable

The last piece to crack in great retrospectives is to make them actionable. We have experienced that teams often struggle to turn discussions in team retrospectives into concrete action. Having the right tools available can make the difference between action and inaction.

Swarmia is here to help you conduct great retrospectives whether it comes to preparing, conducting or turning them into concrete action:

Before the retrospective

Explore your team's data on Swarmia to prepare for retrospectives by discovering insights and validating hypotheses on what seems to work and where you could improve based on data.

Check the view to identify if there are signs of working alone, siloed work, days without progress or too much reactive work. More information on how to diagnose patterns from Work Log .

Use the view to identify PRs, Tasks, Stories or Epics that took a long time to complete. When you click a dot in the Cycle Time graph, you can dig deeper to what actually happened with the feature each week.

During the retrospective

Pull Request flow is easier to fix than Tasks or Epics, and thus it can be a good starting point for the discussion. It's good to dig deeper into the outliers. Was the scope of this PR too large, and could we have split in other ways? Was it difficult to get a review? Was it clear what's supposed to be done here?

With tasks/issues, the change requires a bit more effort. Developers often like working on their own thing, as you don't have to coordinate much. Changing the behavior requires several things:

  1. limiting Work In Progress

  2. multiple people working on the same task

  3. better planning of the sub-tasks

  4. making sure that sub-tasks are small enough

After the retrospective

Deciding to strive for better planning will likely take a couple of iterations, as it is hard to get right at the first try. Thus, in future retrospectives it's useful to discuss individual tasks and how well they went.

After a good preparation you can focus on well-informed discussion which should result into concrete actions agreed together as a team. Swarmia has built-in that can be set up based on actions agreed upon during retrospective.

If the team decides during retrospective to clean up old Pull Requests and set a Working Agreement for Pull Request age and review times, you can expect to see results in a week (or: just in time for your next retrospective). Enabling makes use of Working Agreements even easier.

Work Log
here
Insights
Working Agreements
team notifications