Apr 27, 2021
Spot and prevent scope creep early on
Remember that time when a small and straightforward project ended up taking weeks or even months to complete? We all have been there. Today we’re excited to introduce new tools to help you diagnose flow issues, recognize scope creep signals early on, and improve planning accuracy.
👉 Select an issue in Work Log to see a burn up chart with all tasks added and completed over its lifetime. New tasks added while an issue is in progress count towards estimated scope creep.
- When tracking commits merged to master without review , you can now see the name of the default branch for each commit in the exceptions list, and each repository in repository settings
- Bugs issue type is now available for all working agreements (e.g. Bugs are closed in under 7 days)
- Performance and stability improvements: we fixed some timeouts and "Unexpected token < in JSON" errors that you might have seen lately
Apr 13, 2021
🔔 Granular control over Slack notifications
Swarmia’s notifications are designed to help you focus, save time, and enable powerful workflows — like linking pull requests to issues — right in Slack. We care about keeping the noise level to a minimum: if you get a notification from Swarmia, it means an action is required from you.
With the latest update, you have even more granular control over notifications you get from Swarmia. Now you can choose what comments and PR-related updates you want to be notified about.
- You can now edit GitHub, Jira, Linear, Slack data associated with your Swarmia account.
- Improved accuracy when calculating cycle time in Pull Request Insights
- All charts under Flow Insights now include rolling average lines
- Improved error handling and stability of the app
Mar 31, 2021
New insights into your pull request workflow
Getting high-quality data about your pull request pipeline is the first step to a better understanding of process changes that improve velocity and quality. Our new pull request insights are here to help. See some key highlights below.
➡️ Cycle time average graph (on the right) shows how long it generally takes you to close pull requests, and how the situation develops over time. If you close pull requests timely, it trends down. Pull requests left open for several days result in an upwards trend. Aiming to close all pull requests in under a week (or 1–2 days on average) is a good starting point for uninterrupted delivery.
⬅️ Pull requests in progress graph (on the left) gives a clue into how your ability to close pull requests is affected by the number of pull requests worked on at once by the team. Working on too many pull requests at once can result in longer delivery times, and we recommend adding a work in progress limit (e.g. up to 7 pull requests open at once) to make sure pull requests piling up don't slow down the team.
➡️ Cycle time distribution chart (on the right) shows what portion of pull requests takes longer than expected to complete, and individual pull requests are shown in the scatter plot on the left. Pull requests far above the rolling average line need special attention — it’s the code that’s been waiting for the longest to be delivered.
Filter the pull request table by status, repository, or author (by clicking the filter icon in the table header) to identify problematic pull requests. Filters apply to the table as well as the charts above.
Review time is another important contributing factor to cycle time. Sorting the table by review time helps to identify pull requests that have spent the longest in review — or have been merged without review at all. The number of pull requests merged without review is reflected in the review rate above the charts.
Tasks completed with no coding activity are now shown at the bottom ofWork Log making it easier to see where the engineering team’s focus has been week to week.
Mar 17, 2021
Pull Request Archive for old and stale pull requests
Old open pull requests can make pull request cycle time metrics difficult to interpret. Our new Pull Request Archive provides you the option to hide old and stale pull requests in Swarmia. This is especially useful for you to start focusing on improving ways of working when adopting Swarmia without letting the burden of the past get in your way.
If your team has pull requests with no activity since the last 30 days Swarmia prompts you the option to archive them on the Pull Request view.
Archived pull requests are excluded from all metrics in Swarmia and Slack daily digest. After archiving, you can still browse them on the Pull Request view.
Your colleagues can now sign up to Swarmia directly from our website. Based on the new user's GitHub account details, we can identify and link the user to your organization in Swarmia. In addition to providing a self-signup option, you'll still have the option to share an invite link (available on theapp front page) with your colleagues.
Mar 2, 2021
Track unreviewed code pushed straight to master
Code review helps ensure code quality, and share knowledge within the team. Yet even among teams performing code reviews regularly, pushing unreviewed code to master is not uncommon. Our new working agreement helps track all commits merged to your main branch without review, and start a conversation within the team if it becomes an issue.
See how your team is doing under Explore → We don’t push code directly to main branch. Connect Swarmia’s Slack digest to get a daily summary of all unreviewed code pushed to production.
Select what teams to see in Swarmia
Now you can choose GitHub teams to show in Swarmia, and hide teams that do not represent actual development teams in your organisation: for example, if you use teams for access control. We’ve hidden some of these teams automatically based on Swarmia usage. 👉 See them all here.
- Pull request dots in all scatter plots now link to GitHub
- Better auto-complete suggestions when searching for projects in Jira configuration settings
- Switching the team now preserves the selected working agreement
Feb 15, 2021
Pull request cycle time trendline and breakdown by stage
A software team’s velocity is a combination of many factors. Looking into pull request pipeline by stage is a great starting point to identify bottlenecks and get pull requests through faster. With the new cycle time breakdown it is easy to see whether review, merge, or WIP time takes longer than expected.
You can also use Swarmia’s filters to look at cycle time and throughput metrics for bot-created, cross-team, and other PRs separately.
The chart below cycle time shows how your pull request queue trends over time. When multiple pull requests are left open for long, it trends up. When pull requests are merged timely, it trends down. Many teams will notice that Christmas bump on longer timeframes where cycle time increases during holiday time 🎅.
Pull request age now includes the time since the first commit
Previously, pull request age was calculated from the moment a pull request was created, and earlier commits would not get reflected in cycle time insights. Including time since the first commit allows better comparison between pull requests and makes pull request insights more accurate.
- Throughput (pull requests merged per day) chart got updated, and now includes the total number of pull requests merged in the selected timeframe in addition to the daily average.
- Cycle time and throughput metrics now include a comparison to the previous time period
Feb 2, 2021
See 365 days of work at a glance with the new high-level Work Log
Our goal at Swarmia is to help teams to get a holistic picture of where their time goes, improve flow and make better planning decisions.
Using Work Log is an excellent way to keep track of day-to-day work and spot patterns like siloing, reactive works, and multi-tasking early on.
With the new high-level Work Log, it’s easy to zoom out and see everything you worked on over the past year. Use it to diagnose flow interruptions, spot never-ending projects, and prepare for team retrospectives.
It’s also a great tool to see just how much you got done and celebrate your progress with the team 🥳.
Working agreement to help you link pull requests to issues
Knowing where the time goes starts with bringing together the data from where work happens. Linking pull requests to issues is a great starting point. It enables better Work Log insights and helps the team to have more informed conversations about how to organize the work.
- Now you can see all PRs where you were mentioned in 💬 Participating tab in PR overview
- Fixed an issue where some at-mention notifications would not be delivered
- Stability improvements
Jan 12, 2021
Rich preview for personal notifications
Sometimes a PR in review might get a lot of comments, but they`'`re all just observations. Now you can immediately tell from the Slack notification if your PR is good to go or has anything left to improve. Configure personal notifications here.
Don’t miss new comments in PR review threads you respond to
In a well-functioning team, PR reviews move forward fast, and resolving issues highlighted in review is a priority. Now, as you reply to a PR review thread, you will get notified about all new comments until the thread is resolved.
Bot PRs get a new home
Following up on the latest updates to the PR overview helping you manage your team’s PR inbox, we’ve added a new section for bot-created PRs.
For all bot users in your GitHub organization, you should be able to see their contributions in Swarmia already. You can also assign bots manually in contributor settings.
- Swarmia holds internal security reviews, and a staff security training every six months. Latest review took place in December 2020.
- You can now get Swarmia team updates & daily digest not only in public but also in private Slack channels. Use our guide to get started.
- Now you can see the weekly number of bug fixes in Work Log.
- PRs labeled as Bugs now appear in the Bugs lane in Work Log even if not linked to an issue.
Dec 8, 2020
A better way to manage pull requests
Swarmia continues to build tools that surface the otherwise invisible work in software teams and help you get a clear picture of your pull requests inbox. Now we’re adding new essential filters providing an at-a-glance overview of all pull requests in both personal and team context:
- Unlinked. Pull requests that are not linked to an issue.
- Participating. Pull requests where you are a reviewer, author, or commenter.
- From other teams. Pull requests created by other teams, and assigned to your team to review.
- 24h stale and over 7 days old. Best kept empty.
Soon, bot-created pull requests are getting a new home too. Contact us for more details.
- Fixed an issue where some mentions wouldn’t be delivered via Slack. Another great reason to enable our personal reminders.
- Fixed an issue where some stale pull requests would show up twice in pull request overview.
- Improved error handling across the application.
- Improved organisation onboarding.
Nov 23, 2020
Predict & prevent exceptions to working agreements
Working agreements are a powerful tool teams use to adopt and keep track of better working habits. Every once in a while, an exception to the rule occurs, and Swarmia already helps you to review those old PRs or a never-ending story that escaped your agreements in the recent past.
Now it’s even easier to prevent future exceptions as you can keep track of all that escapes your agreements ⏰ right now. Aim for inbox zero, and review your agreements with the team frequently to make sure the new habits stick.
Working agreements work best with the daily digest. Once an agreement is adopted, it appears in the digest with a link to all active exceptions.
Improved pull requests overview
Keeping pull requests inbox in order is the foundation of a healthy software team. With the updated pull requests overview, it's easy to see all work in progress at a glance:
- Pull requests are divided into groups: ready to merge, waiting for review, and in progress. It's clear what action is required next.
- Pull requests with no activity for over 24 hours are labeled Stale. Take care of these first.
- See review status, all contributors (authors, reviewers & commenters), comments, and CI build status for each PR.
This update is part of a series that makes Swarmia your go-to place for everything PR-related. Coming next:
- Filter for stale, old, unlinked pull requests
- All pull requests where you participate (as an author, reviewer or commenter) in one place
- Pull requests from other teams, assigned to your team for review
Share your feedback and suggestions at firstname.lastname@example.org, or using the chat button anywhere in the app.
- Team selection is now preserved in the URL. Now it's easy to bookmark and share Swarmia pages of the teams you follow.
- Improved handling of commenting bots, more bots are excluded from the pull requests overview + Swarmia notifications
- Now pull requests are labeled Stale in the daily digest only after 24 hours of no activity
- Added support for canceled and archived Linear projects
- Improved accuracy when calculating issue lifetime in the Work Log
Nov 9, 2020
Daily Digest update
Making a long-lasting improvement to working habits is impossible without a strong feedback loop. With that in mind, we've built our Daily Digest — a Slack update aligned with your daily stand-up meeting that provides a brief summary of pull requests, issues, and working agreements that need your team's attention,while keeping the noise level to a minimum.
Now it's even more actionable and concise:
- Take action: see pull requests waiting for review & ready for merge
- Draft, in-progress, as well as closed PRs, are not shown
- ❗️Stale and ⏰ Old pull requests are highlighted
- See the number of open vs. completed tasks for issues in progress
Set up your digest in Settings. Make sure to select your team's main Slack channel for better visibility. We're eager to hear your feedback, feel free to send us a message using the chat bubble in the bottom right corner of the app.
- Weekends are now excluded for pull requests marked as Stale in the Daily Digest
- Pull request review time chart now shows the target you have chosen when setting up a new working agreement
- Contributor management improvements
- Improvements to y-axis labels for review time chart
Nov 2, 2020
Progress bar for issues with subtasks
See all completed, in progress, and to-do subtasks in a progress bar below each issue in the Worklog. Now it easier to stay up to date with the issue scope, and status of subtasks in your projects.
Issue lifetime contributors
We continue adding improvements to Work Log that give you a broader context to issue activity. Now we show everyone who has worked on an issue over its lifetime, with recent contributors highlighted.
- Working agreements preview now updates live when configuring a new agreement
- Improved error handling, now it is less common for entire pages to fail with an error
- Deleted GitHub teams are not visible in Swarmia anymore, but historical data in all charts is preserved.
- Subtask icons are now shown in the Work Log
- Swarmia GitHub bot now posts issue linking confirmation comments to all pull requests
Oct 19, 2020
Swarmia’s Working Agreements have already been helping teams when it comes to managing work in progress and cycle time. Many teams have found them especially useful to manage issue workload, and to get notified when issues are taking too long. However, a limitation so far has been the ability to only create working agreements about one issue type.
Add Another Working Agreement
Managing the amount of work in progress is one of the most effective ways for a team to maintain focus and deliver tasks quickly. Imposing work-in-progress limits for Stories has been an important tool for teams struggling with too much work, but this has precluded setting similar limits for Epics, Tasks, or Bugs. At the same time, most teams have an idea about how long different tasks should take. For example, Stories should usually be completed within a week or two, whereas Tasks can be significantly shorter, and Epics significantly longer.
Swarmia now allows teams to adopt multiple copies of issue related Working Agreements. For example, teams can impose work-in-progress limits for both Stories and Epics, and also manage the cycle times of both issue types. If you’ve already adopted Working Agreements about the number of Stories open at once, or targets for closing Stories, navigate to the Explore tab in Working Agreements, select either working agreement, create a new configuration, and click Adopt another.
In this case, a team that has already agreed to have a maximum of three Stories open at once can adopt another Working Agreement, this time limiting the number of Epics open at once to one. Adopting multiple, identical Working Agreements is of course not supported or useful. Adding multiple copies of Pull Request related Working Agreements is also not supported.
Pull Request Review Distribution
Our new Insights about Pull Request review times have been useful for teams with delays in this crucial step. Most teams are mostly alright in terms of review times, with significant outliers causing problems. To help teams understand the magnitude of issues with Pull Request review, we’ve added a new histogram that shows the distribution of review times, and we also now spell out the median review times separately for all issues, issues reviewed by the team itself, and issues reviewed by other teams.
- Small UI improvements to charts in Working Agreements
- Tooltips in Pull Request Insights show contributor avatars and review conclusion
- Charts in Working Agreements show the limit line instead of the median
- Small fixes to how we calculate unplanned work in Work Log
Oct 12, 2020
Swarmia’s Insights already help you keep track of your Pull Request and Issue cycle times, and we also let you set targets for Pull Request cycle time with a Working Agreement. This week, we’re releasing new features that help you drill down to the Pull Request review time, and to set targets for Issue cycle times.
Pull Request Review Time
Making sure that code is reviewed without delay is one of the most important things you can do to improve team dynamics and throughput. Our new Insight and Working Agreement lets teams specifically improve the time it takes to review code. The time to review code is a leading indicator of the Pull Request's total cycle time, and counting working days only lets the team set aggressive goals for this crucial step.
A new scatterplot in Pull Request Flow Insights shows how long it takes to provide a review after one is requested. To help organizations dealing with delays caused by cross-team dependencies, reviews provided by other teams are highlighted in a different color.
The corresponding Working Agreement helps your team step up your Pull Request review game by setting a target for how many working days Pull Requests wait for review.
As with other Working Agreements, details about exceptions help your team troubleshoot your process in retrospective meetings, and instant feedback in the daily Slack digest helps you address issues with Pull Requests reviews as they occur.
You can read more about why and how to review code faster in our Support Article.
Manage Issue Cycle Time
Most teams have a rough idea of how long it should take to finish an Epic, Story or Task, but it’s common for progress on Issues to stall for a multitude of reasons. Our new Working Agreement helps teams manage cycle time by setting targets in calendar days and highlighting exceptions.
In addition to the Working Agreement page and the daily Slack digest, issues that are taking too long are highlighted in Work Log to help teams analyze exceptions in context.
- In addition to Work Log, the Issue Activity popup can now be opened by clicking an issue in Flow Insights
- Improvements to Insights visualizations, including separately showing the Median
- Small fixes to how Pull Request categories are displayed in Work Log
Oct 05, 2020
Linking Pull Requests to issues from your issue tracker is the best way to keep tabs on your team’s focus and flow using Work Log. But when teams self-organize around caring for a codebase, it’s just natural that not all Pull Requests can be linked to an issue.
Pull Request Categories
It’s great when teams take ownership of their code and deal with small bugs, chores and improvements right away, but it’s still useful to understand where the team’s efforts are spent. This week we’re introducing a powerful new feature to categorize Pull Requests without linking them to issues.
Previously, all unlinked Pull Requests were plotted on the Uncategorized row in Work Log, with no quick way to identify what kind of work it was. The new Pull Request Categories feature lets you assign unlinked Pull Requests to one of four categories: Bug, Improvement, Chore, or Refactoring.
Unlinked Pull Requests can be assigned to a category by selecting it in the familiar dropdown menu in the Pull Request dashboard:
As usual, we notify you on Slack when merging an unlinked Pull Request. Now you have the option to click a button labeled It’s something else and select a category:
As a result, Work Log shows a much more accurate view of where the team spends its focus. Unlinked Pull Requests assigned to the Bug category are plotted right on the Bugs swimlane, and the newly renamed Unplanned swimlane shows a breakdown of the week’s unlinked Pull Requests by category.
- Fixes to calendar rendering in Issue Insights when an issue has been open for a very long time
- Stopped sending Slack messages about edited Pull Request comments
- Fixed small issues with handling GitHub Check Runs
- Performance improvements to Continuous Integration Insights
- Pull Request comment about issue linking now shows the full issue hierarchy
Sep 28, 2020
Work Log already helps you visualize where your team’s focus is spent on a weekly basis and to identify common patterns having to do with team dynamics and focus. The all-new Issue Insights feature lets you drill down deeper on an individual Epic, Story, Task or Bug to find out how your team organizes around issues, and what you could do to increase focus and accelerate delivery.
Drill Down on Issue Flow
Navigate to Work Log and click on an issue. This opens the Issue Insights popup that shows a number of key facts.
Open days is the number of calendar days since the first linked GitHub activity, or since the issue was marked In Progress. Active days is the total number of days with activity linked to the issue. Efficiency is the ratio of Active days to business days.
The calendar shows the intensity of activity linked to the issue per day: the darker the shade of blue, the more activity on that day. To take a closer look at what your team was working on in a given week, clicking a week in the calendar takes you to that week in Work Log.
Ideally, we want to see long streaks of dark blue in the calendar. Teams that put in big chunks of focused work tend to finish fast, even if efficiency is under 100% — short interruptions like vacation days and urgent bugs are hard to avoid completely.
Often the reality is that team focus is stretched too thin. Even with 100% efficiency, progress can be slower than necessary if contributors are working alone or there are many concurrent topics competing for the team’s attention. This is evident in the issue insights calendar when progress is steady, but most days are a lighter shade of blue.
Unfortunately, it’s all too common for teams to be inundated with work in progress and constant interruptions. Slow progress with lots of waiting is clearly visible in the issue insights calendar with long periods of grey inactivity interspersed by light-blue days here and there.
How is your team doing? Head over to Work Log and click on some issues to find out!
Issue Link in Pull Request Comments
To get the full benefits of Swarmia’s Work Log and the new Issue Insights, it’s important to get into the habit of linking Pull Requests to Jira issues. Swarmia now posts a comment in each linked Pull Request to confirm that it’s been linked, as well as to help you quickly check the respective Jira issue for scope, designs and other context by following the link in the comment.
New Issue Tracker: Linear
In addition to Jira, most Swarmia features are available now for Linearusers as well. Link Pull Requests, view Work Log by Linear project or issue, and view Insights about Linear projects and issues. Let us know if you’re using Linear and would like to look beyond Pull Requests with Swarmia!
- Lots of small optimizations amounting to a significant performance boost
- Cycle Time metric now includes merged Pull Requests only
- Slack notifications are sent about @mentions in GitHub comments
- Lots of small UI tweaks and bugfixes to improve usability
Aug 5, 2020
Introducing Working Agreements
We believe in self-organizing teams that own their ways of working. With Swarmia, teams already get full visibility into their process and can identify potential improvements — but transparency alone is not enough to become better and stronger as a team. Working Agreements is a powerful new feature that helps teams continuously improve with clear goals and consistent execution. Our first iteration includes features to manage the amount of work in progress and the cycle time of Pull Requests.
Manage Work in Progress and Cycle Time
Managing the amount of work in progress and reviewing code without delay are some of the best ways for teams to improve their speed and focus. Our first Working Agreements allow teams to set work-in-progress limits for issues and Pull Requests, and to set a limit for Pull Request age.
Ready to jump in? Why not have a conversation with your team and head over to the new Working Agreements area in the app to get started.
Working Agreements are simple to configure and adopt, and insights about the Working Agreement as well as details about recent exceptions are clearly visible in the UI.
Finally, the daily Slack notification shows how the team is doing with their Working Agreements, helping teams adopt new habits with immediate feedback. If you haven't enabled Slack notifications for your team yet, now is a good time to do it!
What Working Agreements does your team use, or would find useful? We have lots of ideas about what to do next, but we'd like to hear from you.
- Cycle Time graph in the Pull Requests view updated to scatterplot
- Continuing to adopt our new design in frontend
- Performance improvements
Jul 13, 2020
The new Working Agreements feature is due for release in the coming days. Meanwhile, enjoy some new Insights about cycle time!
New Flow Insights: Cycle Time
As mentioned in the previous feature update, managing the amount of work in progress is a great way to get work done faster.
New Cycle Time Insights plots completed issues on a timeline and shows how long they were open. The scatter plot makes it easy to identify outliers and trends, and drill down on individual issues.
Can you find correlations between the amount of work in progress and cycle time for your team?
- Significant Work Log performance boost
- Usability improvements to tooltips in Insights
- Improved color palette for data visualizations
- Numerous small usability and UI improvements
Jun 23, 2020
Introducing Flow Insights: Work in Progress
Managing the amount of work in progress is one of the best ways for a team to improve focus and get work done faster.
Flow Insights plots the number of open Pull Requests, Epics, Stories and Tasks on a timeline, helping teams understand how much work they have on their plate at a given time.
Lots of Work in Progress usually correlates with longer cycle time and intermittent progress, which is something you can identify in Work Log. What correlations can you find?
- Usability improvements/fixes in Personal and Slack settings
- Improvements and bugfixes to Insights charts and tooltips
Jun 15, 2020
Work continues on the Insights product area. This week we are adding Quality Insights to help teams stay on top of their Continuous Integration pipelines, and working on all new Insights about flow.
Quality Insights: Build Time
In addition to flaky builds, Continuous Integration Insights has a new tab that plots build times on a timeline. Drill down to a given day to see the average build runtimes and the number of builds.
Coming soon: Controlling the amount of unfinished work is a great way to stay focused and improve flow. Find out next week how we can help teams locate bottlenecks and understand how much work they have on their plate!
- Small usability improvements in Work Log
- Improved database and app performance
- UI tweaks and small bugfixes to Quality Insights
- Usability improvements in Team and GitHub Settings
Jun 8, 2020
We're starting to develop a new product area called Insights to help teams form a holistic view of their ways of working. The first Insights are about quality: bugs and continuous integration.
Introducing Quality Insights
Bug Insights shows the volume of bugs on a timeline and how many bugs you are opening and closing on a daily basis, based on your team's Jira data.
Continuous Integration Insights plots the daily percentage of flaky builds on a timeline. You can drill down to a given day to see how many builds were flaky and how much time was wasted waiting for them to complete.
Next up: build duration. Stay tuned, and don't forget to let us know what you think!
- Work Log shows all issues that your team has worked on even if they are assigned to other teams
- Work Log shows both Tasks and Stories under Other Issues in Epic view
- Usability improvements in Jira Settings for larger organizations
- Small fixes here and there