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'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’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.

We’ve made several improvements to make it more clear how we track Git users and added support for excluding pull requests created by specific users. 

Git Users include anyone in your GitHub, GitLab, Bitbucket, or Azure DevOps organization. You can view a list of Git Users in your organization’s Settings under the Git Users tab.

Git Users include both Current and Past users contributing to repositories in your organization. Past Git Users are included in your historical data.

You can manually exclude pull requests created by 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).

Pull requests created by bots are automatically excluded from your data. Their reviews and other pull request activity are not factored into any metrics. If we are unable to automatically detect bots in your Git organization, you can manually exclude all pull request activity from those users.

Open source contributors are also automatically excluded from your data. An open source contributor is any user that is not an organization member and only contributes to public repositories.

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

To ensure your lead time metrics reflect work that is actively in the review and merge pipeline, we've refined how draft pull requests are handled. All stages, including "Time to Approve," now consistently exclude drafts, giving you a cleaner signal on the efficiency of your active development efforts (note: there is no change to how “Time to Review” is calculated, which still starts when a pull request is opened or marked as ready for review).

These updates are designed to give you a truer, more actionable understanding of your team's development velocity. If you have any questions, please reach out to us at support@software.com.

We’ve updated the name of the “Features” metric to “New Deliveries” to avoid confusion with project management terminology. This change is purely naming-related and does not impact how the metric is calculated or displayed.

We’re making an adjustment to improve the accuracy of our data — specifically, how we track the amount of code that is New, Churn, and Refactor. These updates provide a more accurate view of changes over time, especially for teams that ship new code iteratively.

You may see adjustments to your metrics and benchmarks—most notably, an increase in New Units per Developer (formally Features per Developer) and a higher percentage of pull requests categorized as New. Since these improvements apply to historical data as well, your data will be uniformly adjusted upward, maintaining all relative differences and trends.

By tracking a more detailed history of file line changes—including both their original position and where they appear after edits—we are now more precisely differentiating between newly written code and modifications to existing work. This added granularity gives a more refined view of how code evolves over time, ensuring that new work is accurately captured and modifications are correctly attributed.

You can learn more about how pull requests are categorized in our documentation. If you have any questions, feel free to reach out to us at support@software.com.

We’ve updated our algorithms to more precisely track your lead time and productivity metrics.

1. Lead Time Stages

   Lead Time is incrementally updated when a PR completes a stage, rather than waiting for the PR to complete all stages. For instance:

   • Previously, Time to Review was updated after a PR was merged.
   • Now, Time to Review is updated when a PR is reviewed.
   • This change ensures that your Lead Time metrics are more timely and reflect an ongoing historical trend.

2. Excluded Pull Requests

   Our algorithm automatically excludes pull requests that are not representative of development productivity, such as those authored by bots and backmerges from main. We also exclude pull requests that are part of your release process (e.g. promoting changes from a release branch to main). We’ve refined our algorithm to more precisely detect these pull requests, such as by detecting re-used branches. Depending on your development process, you may notice a slight increase in your pull request metrics.

If you have any questions about how our algorithms work, feel free to reach out to us at support@software.com.

Based on feedback from our community, we’ve improved our Features per Developer metric to better standardize industry benchmarks and provide better accuracy when comparing groups within your organization, such as developers using vs. not using GitHub Copilot.

As part of this update, the developer count will include contributors who created a pull request in the last 90 days. Previously, the developer count included any contributor who created or reviewed a pull request in the last 30 days.

Extending the activity window from 30 to 90 days accounts for seasonality, providing a more stable representation of your organization’s size over time. Developers who leave your organization are counted towards historical activity, but immediately removed from your developer count going forward.

Cost per feature still includes contributors who created or reviewed code in the last 90 days—to more precisely capture the costs associated with developing, reviewing, and delivering features. Development costs are calculated by multiplying a group’s cost per contributor by the count of developers and reviewers within the group.

You may notice small changes to your metrics and global benchmarks. You can read more about this change in our documentation, or feel free to reach out to us with any questions at support@software.com.

We’ve improved our feature calculations to automatically ignore pull requests in development workflows—such as dependency updates, back merges, and releases—that are not representative of developer productivity. These improvements have been requested by customers. As a result of this update, you may see a slight decrease in features per engineer, and industry benchmarks will be more accurate.

A pull request is excluded from your metrics if it meets any of the following criteria:

• It is authored by a bot (e.g. a dependency update)
• The head branch is the default branch (e.g. a back merge to sync changes from default into a development branch)
• It does not include any unique commits that haven’t already existed in a previous pull request (e.g. merging a release branch into main)
• More than three authors merged a pull request into the head branch (e.g. a long-lived feature branch)

You can review the list of pull requests that are included/excluded in our definitions by hovering over a data point and viewing more pull requests in the flyout.