We've rolled out an update to ensure that your Time to Develop metric more accurately reflects the active development time for the work being shipped. It provides a cleaner signal by removing the noise from routine branch management and code integration tasks.

Our refined algorithm filters out unrelated commits from actions like changing a base branch or merging in hotfixes. Each commit is now only associated with a single pull request and will be excluded from the calculation if it meets any of the following conditions:

1. It was already part of a merged PR. This filters out standard merge commits and commits from other branches (e.g. a hotfix) that were merged into the feature branch before the PR was completed.
2. It results from a base branch change. We ignore commits that are temporarily added to a PR's history when its base branch is changed, ensuring only commits relevant to the final base branch are included.
3. The author and committer are different. This excludes commits that were authored by another developer and introduced into the branch history through actions like cherry-picking.

These changes are detailed in our documentation. If you have any questions, please reach out to us at support@software.com.

On Leading Indicators, we automatically flag the stage where uncompleted work is piling up to indicate where there is a traffic jam in your process. We've rolled out three key refinements to how we visualize work in progress:

• Separation of Abandoned PRs: We now separate abandoned work, giving you a cleaner view of your team's in progress work and making it easier to visualize your most constrained stage.
• Improved Abandoned Threshold: The threshold for marking a PR as abandoned has been increased from 30 to 90 days to better account for long-running but still relevant work.
• Completed Work Toggle: We’ve added a toggle to show completed work for historical context. By default, completed work is not shown. 
• Consistent Group Attribution: We’ve improved attribution of abandoned PRs to groups where the member who authored the PR is no longer part of a group.

We’ve released an important update to our roles and permissions model, giving you more granular control over who can access and manage different parts of your organization.

This update introduces four distinct roles—Contributor, Manager, Director, and Admin—each with a clear scope of permissions across features and settings. Contributors are limited to read-only access, Managers can edit groups and manage their teams, Directors can create comparisons and view cost data, and Admins retain full access across the platform.

As part of this change, existing users with the Member role will automatically become Contributors, while existing Admins will remain Admins. Members who previously had access to Comparisons and cost data will be transitioned to the Director role. Going forward, all new users will default to the Contributor role.

If you’re an Admin, we recommend reviewing your team’s role assignments. Members who previously managed groups and repositories will now need to be promoted to Manager to retain those permissions.

We’ve also added group-based access controls. By default, users can access all groups, but Admins can now assign specific groups to Contributors and Managers to limit what data they can view and manage.

These changes provide better alignment with how organizations structure their teams and ensure sensitive data is only accessible to the right roles.

You can learn more about the updated roles and permissions in our documentation. If you have any questions, please reach out to us at support@software.com.

We’ve refined our algorithm for Code Review Cycles to provide a clearer signal on the back-and-forth context switches between authors and reviewers. 

With the rise of AI code review tools, developers should not see their metrics negatively impacted for using modern tools that help them improve code quality before human review. For this reason, we’ve made an update to exclude reviews from bots from the calculation.

We’ve made several other refinements, such as excluding reviews and comments by the pull request’s author, reviews that happen before a pull request is marked as ready for review (i.e., taken out of "Draft" status), and reviews from open source contributors.

With these changes, you may see a decrease in the Review Cycles reported for some pull requests. This adjustment applies historically, ensuring that your trends remain consistent while improving the overall accuracy of the metric. The result is a more precise and actionable measure for understanding and improving review efficiency.

You can learn more about how we calculate Review Cycles in our updated documentation. If you have any questions, please reach out to us at support@software.com.

We’ve added support for nesting groups within groups, allowing you to more easily visualize data according to your organization's structure. Changes to child groups will be reflected in parent groups, reducing the time required to manage and update groups.

Here’s a quick overview of the improvements you’ll see across the platform:

Nested Group Filter

The group filter is now organized by group hierarchy, allowing you to navigate through groups according to your organization’s structure.

Drilldowns

Filtering to a parent group also displays child groups within the group breakdown table, allowing you to more easily compare metrics across groups.

Group Settings

You can now assign child groups to a parent group. Parent groups will automatically inherit the members and repositories assigned to child groups.

Here’s an example of how it all works:

• You create a group called Product Engineering.
• You add three child groups to Product Engineering: Mobile App, Web App, and APIs.
• Product Engineering inherits the members and repositories assigned to each of the three child groups. That means removing a member or repository from a child group will also remove them from the parent group.
• You can assign additional members directly to Product Engineering (e.g., Managers or Staff Engineers that might oversee all three teams) without affecting child member inheritance.
• If you choose to assign repositories to Product Engineering, repositories will not be inherited from child groups. This allows you to ignore contributions to certain child group repositories that may not be representative of the parent group’s work.
• Members can have multiple membership records. For example, if someone leaves and then rejoins a team, you can set join and departure dates to accurately capture that member’s tenure and contributions on each team.

Child Membership Updates for Imported Groups (GitHub Teams and GitLab Groups)

• Previously, members of a child group were automatically added as direct members to the parent group.
• With this update, child group members are now shown as inherited members of the parent group instead of being added directly.
• To support this change, their former direct memberships were marked as “removed,” which is why they now appear in the Past members list.
• This change will have no effect on your data.

These updates give you more control and visibility into group structures and history—especially useful for large or dynamic teams.

If you have questions, please reach out to us at support@software.com.

We’ve rolled out an important update to our role-based permissions to give you more control over your organization's security and settings. These changes are designed to ensure that only Admins can modify critical settings, providing clearer roles and better control over your organization's workspace.

Here’s a summary of what has changed for the Member role:

• Organization Settings: Members can no longer edit organization-level settings (e.g., display name, industry reference class).
• Git User Management: Members can view the Git Users list, but cannot change user exclusions.
• Strategic Events: Access to the Strategic Events tab is now restricted, unless an Admin has granted access to Comparisons.
• Billing & Connected Apps: The Billing and Connected Apps tabs are now only visible to Admins.

Our updated documentation on roles and permissions can be found here.

As we continue to improve our role-based access controls, these changes will ensure that your organization's data and settings are secure by default. If you have questions, please reach out to us at support@software.com.

We’re excited to announce that our Developer Insights page now supports organizations using Azure DevOps. Previously, this feature was only available for GitHub, Bitbucket, and GitLab (cloud) users. 

Developer Insights provides personalized metrics that give you a deeper understanding of your engineering contributions. These insights are designed to help you understand your impact, spot bottlenecks, and continuously improve your development workflow.

Only you can see your Insights page. You can download your report if you'd like to share.

We've made a few small fixes and improvements to the Deployments report:

• Slowest and Least Successful Deployments: To provide you with more relevant and timely insights, Slowest Deployments and Least Successful Deployments will now reflect data from the last complete month instead of the last three months.
• Highlights: The 3-month rolling averages no longer include the in-progress period, providing a more accurate representation of historical performance.
• More Accurate Group Representation: When selecting a Git provider group (e.g. a GitHub team), data starts after the group was created, providing a more representative group history. This matches the behavior on newer reports, like the KPI report.
• Time to Deploy: We’ve corrected a discrepancy in Time to Deploy between the Deployments report and KPIs report. This adjustment ensures that the Time to Deploy metric now aligns with the drilldown and KPI views.
• Batch Size: We've resolved a bug affecting a small number of teams where line changes may have been counted twice.

 If you have questions, please reach out to us at support@software.com.

We have corrected an issue in the weekly group email report to ensure it consistently displays the most recent week’s data. This resolves a problem where reports sent in May and June inadvertently showed data from a prior week. No other reports were affected.

We have released a fix and added enhanced monitoring to prevent this from happening again. We apologize for any confusion this may have caused.

We’ve made a few important updates to improve groups—including more robust configurations, easier management, and clearer representation of memberships. There is no change to any of your metrics as a result of these changes.

—

New Membership History

Set a Join and/or Departure date on a group member to limit their data to a specific window of time. Members with a Departure date can be found under the Past tab under Members.

Use this feature to more accurately reflect teams where members are changing over time. You can also exclude data for managers that were previously ICs while retaining the data before they changed roles. To compare AI coding tools, use this feature to limit data for each developer in the group to after they started using the tool.

History of members joining or departing a group is automatically retained for teams synced from your Git provider (e.g. GitHub Teams). You will now see Join and Departure dates displayed for members of these synced groups. There is no change to your metrics as a result of this change, unless you choose to manually modify Join and Departure dates.

Faster, More Efficient Group Management

We’ve implemented a faster, more efficient user interface for adding members to groups. You can now add members to groups from the Git Users page.

You can add multiple membership records for a single user, spanning different periods of time. Use this feature to capture users that joined, left, and then rejoined a group. There is no change to bulk add or delete members from a group, aside from a small change to the terminology (“delete” vs. “remove”).

Clearer Representation of Group Membership

Group membership counts—as shown next to each group for context—have been updated to include Git users marked as excluded (e.g. managers) or bots. Previously, these users were not included in the count.

Contextual member counts are no longer displayed for groups in KPIs, Leading Indicators, and Comparisons to avoid confusion. Instead, a count of developers—anyone who created a pull request in the last 90 days—is now shown for metric drilldowns when it is relevant, such as for New Deliveries per Developer, Code Review Participation, and Open Pull Requests per Developer.

As a reminder, you can exclude pull requests created by a user (e.g. managers, product managers, designers, and other Git users outside of engineering). Reviews and approvals from these users will still count towards the progress of your pull requests to preserve accuracy (e.g. calculating Time to Review), but they will not factor into contributor-based metrics (e.g., Developer, Reviewer, and Contributor counts). You can also exclude all pull request activity for a specific user. Their reviews and other pull request activity are not factored into any metrics.

—

These changes aim to provide more accurate data and a more intuitive interface for managing group memberships. If you have questions, please reach out to us at support@software.com.