How to Find Pull Request Metrics in Bitbucket

December 21, 2023
#Analytics#How To#Project management#Bitbucket#Reporting
9 min

Measuring pull request metrics in Bitbucket can be tricky and time-consuming, as it encompasses a wide range of data scattered around different repositories, teams, and projects. This article will explore what PR metrics are worth tracking, why, and how to find them using an on-prem app called Awesome Graphs for Bitbucket.


Awesome Graphs for Bitbucket is an app for engineering managers and their teams that transforms invisible developers’ activities into easy-to-understand graphs and reports. It helps over 1,6K customers, including Apple, Oracle, and MasterCard, manage engineering productivity, remove process blockers, and improve delivery.


Let’s dive into tips for measuring pull request data.

Number of Pull Requests

Tracking the number of pull requests gives an overview of the development activity within a project. However, simply counting pull requests provides superficial information and does not reflect actual team progress. That’s why it is important to look at the number of created, merged, and declined PRs, as well as their ratio.

Creating more pull requests may indicate more active development and a fast-paced project. But, it could also mean higher cycle time if no reviewers are available, increased code complexity, or irrational distribution of efforts if not managed effectively.

Therefore, it is better to look at this metric together with the number of merged pull requests as they generally indicate progress and contributions accepted into the project. They are also one of the indicators of an effective code review process.

Using Awesome Graphs for Bitbucket, visualized statistics of these metrics and their ratio can be found in the Created vs Merged Pull Requests Report. It displays how many pull requests were created and merged during a particular time.

pull requests in bitbucketOne more metric to look at is the number of declined pull requests. While a certain number of them are usual practices due to bugs or outdated changes, high rates might indicate misalignment with project goals, lack of code quality, or poor communication.

The Awesome Graphs’ Pie Chart Report allows you to see the number of opened, merged and declined pull requests and their ratio to assess the health of the development process.

Number of Pull RequestsThis report can also be reconfigured to see the number of PRs merged without reviewers, as code without checking could lead to poor quality, vulnerabilities, or misalignment with project standards, impacting the overall quality of the software.

bitbucket pull request metrics

Pull Request Cycle Time

One more metric that is worth tracking is cycle time. It provides insights into how quickly PRs are reviewed, approved, and merged and helps evaluate a code review process and speed of delivery. Usually, a shorter cycle time means a more efficient development process.

It is also beneficial to examine the four phases of cycle time to see more accurately where bottlenecks and inefficiencies are in the process. Here they are:

  1. Time to Open reflects how quickly the code review process is initiated.
  2. Pickup Time indicates the reviewers’ workload, priorities, and communication efficiency.
  3. Review Time provides insights into the speed of giving feedback, implementation of changes, and reaching agreements.
  4. Time to Deploy shows the speed of delivery to end users.

By using Awesome Graphs, these metrics can be found on the Bitbucket Pull Requests page.

Pull Request Cycle TimeThe app also allows seeing the most frequent resolution times to make more accurate project estimations and spot pull requests that take very long or short to resolve.

bitbucket pull request statistics

Activities in Pull Requests 

The number of comments and the level of engagement from reviewers contain valuable insights into team collaboration, code quality, and the effectiveness of the code review process. At the Awesome Graphs team, during the code review, we always consider the number of activities in each pull request, as many comments might indicate some issues in the workflow. At the same time, a reasonable amount of discussion leads to higher-quality code and creates a collaborative environment within the team.

The activities in pull requests can be found in the Contributions Report. It shows how many comments each reviewer made in pull requests as well as how many comments each author got from reviewers.

Activities in Pull Requests Apart from out-of-the-box reports, Awesome Graphs for Bitbucket provides the capability to export pull request data to a CSV file or via REST API to build custom reports and gain insights tailored to specific needs.

To sum up, pull request metrics provide an overall view of what is happening in projects and within teams. Choosing the most important ones for you and looking at them holistically will help you make informed decisions based on well-rounded insights, evaluate the code review process, and improve product delivery. Incorporating Awesome Graphs for Bitbucket into your software development workflow will make tracking these metrics much easier and more efficient.

Related posts

    How to Do a Code Review in Bitbucket: Best Practices from Our Team

    November 28, 2023
    #How To#Project management#Bitbucket#Collaboration
    21 min

    In this article, we will spill the beans and share how our team conducts code review in Bitbucket to ensure smooth feature delivery and mitigate risks.

    At Stiltsoft, we have several development teams dedicated to creating apps that enhance the functionality of Atlassian products. Our development team consists of 4 full-stack engineers with accumulated software development experience of over 30 years and focuses on several apps for Jira and Bitbucket. One of them is Awesome Graphs for Bitbucket, which is used by over 1,600 companies, including Apple, Oracle, and Mastercard.

    Table of Contents

    Software Development Workflow

    The illustration of the code review process and its main principles would only be complete by delving into the software development workflow. In our team, this process is structured around the following key milestones:

    1. Solution Proposal
    2. Code writing
    3. Code review and Testing
    4. Release and Deployment

    software development workflow

    Let’s look closer at the first three stages and their peculiarities.

    Solution Proposal

    Before making significant changes to the code, we prepare a Solution Proposal to outline the planned changes and their implementation to our teammates. Significant changes include:

    • adding a completely new feature
    • making substantial changes to UI or changes that impact many files
    • changing backend components
    • integrating new tools.

    Our solution proposal consists of 4 main parts:

    1. Motivation – Why did we decide to work on this issue?
    2. Context of the problem – What is happening now?
    3. Suggested Solution – How exactly are we going to implement this?
    4. Consequences – What changes will this solution entail?

    This is extremely useful, particularly for newcomers who could spend a lot of time implementing a solution that either does not meet our internal standards or could be achieved much easier and faster as we have already resolved such issues. Apart from this, it helps the whole team to:

    • validate the solution with colleagues and avoid “tunnel vision” or reinventing the wheel
    • discuss the implementation of complex issues that are not entirely clear how to solve
    • facilitate the later code review process as teammates are already familiar with the proposed solution
    • check if the suggested solution adheres to the business requirements.

    When the Solution Proposal is ready, the author shares it with the product and development teams and organizes a call in Slack to discuss questions if necessary. These documents are stored in the Confluence product space, ensuring that our team or colleagues can access them whenever needed.

    Code Writing

    Here, we won’t dwell on how to write the code but will describe how the repositories are structured, using the example of one of our apps, Awesome Graphs for Bitbucket. Since the apps for Bitbucket Cloud and Data Center differ in functionality, we have two separate repositories for them. However, unlike the backend, the frontend for both app editions is almost identical. To avoid duplicating features, we allocated the shared part of the code into a separate third repository and connected it as a Git submodule.

    code writing

    It allows us to:

    • maintain consistency across both versions of the app
    • avoid code duplicating and implementing shared features twice
    • reduce redundancy and development efforts.

    However, this solution has its drawbacks, such as:

    1. Complexity in reviewing changes as reviewers might need to navigate between the parent repository and the submodule’s repository to understand the full context of the changes.
    2. Merge conflicts as adding a new feature to the shared code for one parent repository blocks changes for the second repo until we update the submodule.
    3. Submodule updates challenges as we don’t create a separate pull request in the subdirectory. Thus, after merging the pull request into the main repository, the author needs to remember to merge the feature branch of the shared repo to the dev branch.

    How the team tackles these challenges:

    1. We use Submodule Changes for Bitbucket to avoid complexity in reviewing changes. This tool allows us to review code changes in the subdirectory as a part of the main repository. We can leave comments and tasks on the submodule’s code in the pull request of the parent repo.
    2. Possible merge conflicts and the impact of a feature on another parent repo are considered within the Solution Proposal.
    3. We use the internal app to automate the process of merging the feature branch to the dev branch of the shared repository.

    Code Review and Testing 

    Since the details of the code review will be given in the next section, the only thing to mention here is that we create pull requests to facilitate this process in Bitbucket Data Center.

    As for testing, an important point to note is that we don’t have QA engineers. The development team carries out testing to check the code for bugs and errors, and the product team to verify compliance with business requirements. We can use tools like Playwright to automate the process if necessary. The main idea behind this approach is that if a developer writes code conscientiously and pays attention to the quality, there is no need to involve testers. The code owner will understand its behavior and find deviations much better than anyone else. The developer creates tests during code writing to cover at least 80% of the code in the pull request. This is tracked for each commit using SonarQube.

    Now that you know the main milestones of our development process, let’s move on to the main principles of the team’s code review process.

    Code Review Guidelines of Our Team

    When to Create a Pull Request

    We agreed to create a pull request only if it contains code ready for deployment so the app will remain working after its merge. When an author needs feedback on functionality that is not ready for production, alternative ways, such as comparing two branches or requesting assistance in Slack, are used.

    When there are dependent pull requests, the subsequent pull request is created only when the previous one was merged. For example, we recently enhanced one of the reports for the Awesome Graphs app. To avoid making one large pull request, we split the code changes into two parts: frontend and backend. Initially, the author created a pull request to review changes in the backend. Only after its merge did they submit the second one with frontend modifications. This is done to ensure that reviewers don’t get puzzled over determining which pull request to review first and have a clear understanding of priorities.

    In this case, two versions of one functionality may appear in the master branch. As in the example above, we had two backend versions for the same report. That’s why, to indicate our intention to remove the old functionality soon and ensure that another developer won’t start using it, we annotate methods and classes slated for removal in future pull requests with “Deprecated”. This annotation should contain a link to the feature, after which completion, the annotated element should be deleted.

    Pull Request Title and Description

    Creating a pull request is always accompanied by giving it a title and adding a description. The title should be clear and reflect the essence of code changes, e.g., Pie Report Optimization: Backend.

    The description is added so that each reviewer understands what changes will be made and why. It is similar to a short summary of the Solution Proposal and consists of 3 parts:

    • Context. An overview of the initial problem and associated constraints.
    • Solution. Key points of how we resolve the issue.
    • ResultsA brief description of what we will get after implementing this solution.

    code review guidelines

    Pull Request Reviewers

    As our development team is relatively small, we add all members to review a pull request by default. This is done to share knowledge and ensure everyone is aware of code changes. However, if a reviewer cannot participate in code review for any reason, e.g., vacation, illness, or heavy workload, they remove themselves from the list of reviewers. Later, they can rejoin code review if circumstances have changed.

    The main principle is that at least one reviewer should always be available to assess the pull request. Typically, code reviews involve 2-3 developers.

    Once all developers have approved the pull request, the author adds a product team member. This step is essential as the product team tests changes and checks their compliance with the requirements and expected results.

    PR Pickup Time & Review Rounds

    During code review, one of the crucial aspects our team considers is pull request pickup time. We define it as the time from when a reviewer is added to the pull request until their first action.

    The Service Level Agreement (SLA) for pickup time is one working day. The pull request author monitors this, and if no response is received within this time frame, they notify the team in the Slack channel. The second and subsequent reminders the author sends once every 4 hours.

    We clearly define these time frames to avoid making the author guess when they will receive feedback and to enable them to make plans and work on other tasks.

    The same rules are applied to reviewers’ pickup time after changes are made to the pull request. In this case, the author notifies reviewers by adding a comment such as “All comments addressed, please review again.”

    Reviewers, in turn, notify the author of the pull request that they finished the code review by adding “Approved” or “Needs work” status.

    We do not limit the number of review rounds but track the number of activities in each pull request, as many comments might indicate some issues in the workflow. To perform this, we have an internal app for Bitbucket, which counts comments and tasks left in PRs. If this number exceeds 30, this tool asks the author and the reviewers to answer four questions:

    1. What went well in this pull request?
    2. Why do you think there are more than 30 comments and tasks?
    3. What can be done next time to avoid this?
    4. What caused the most trouble in this pull request personally to you?

    how to do a code review

    We review these answers every two months to reflect on the processes, find bottlenecks, and optimize the workflow.

    Pull Request Size

    In pull requests, we look not only at the number of comments but also at their size. Our team believes that a great pull request should strike a balance between being small enough to be reviewed quickly by teammates and comprehensive enough to cover the planned changes or feature additions. That’s why an author of a pull request always strives to make it as simple and clean as possible.

    Moreover, we are considering working on a new report for the Awesome Graphs app. It will enable users to see pull request size distribution and track changes in PR size over time. This functionality is not currently available to our clients, but we’ve made its prototype using the team’s data. Pretty good, right?

    If this report sparked your interest, feel free to contact us. We will be glad to share the details and hear your thoughts.

    pull request size

    Code Refactoring

    When developing a new feature, the author sometimes comes across some parts in the code that they’d like to rewrite and update. This is inevitable as technologies evolve, new tools emerge, and our expertise expands. However, we agreed that refactoring is permitted within the scope of a pull request only if it influences the feature we are working on. Besides, reviewers can request to create a separate pull request for changes related to refactoring or to roll back these changes in case they distract from the review of the main functionality. This is extremely useful for large-scale refactoring as the developer will work on a particular task without investing time in non-priority ones.

    Refactoring unrelated to the current feature is postponed or scheduled for R&D Day.


    Every Friday, instead of working on regular tasks, we focus on enhancing the Developer Experience (DX) and exploring new tools to streamline and improve our processes. Here also come tasks related to refactoring and technical debt.


    Tools for Code Review in Bitbucket

    We’ve already mentioned some of these tools, but let’s put them together.

    Submodule Changes for Bitbucket – a tool that helps review the changes made to Git submodules in the Diff tab in Bitbucket. We use it for two primary purposes:

    1. To review changes in the submodule as if they are a part of the parental repository. We can leave comments and tasks on the submodule’s code within the code review process of the parental repository.
    2. To check a new merge to ensure that the submodule commit can be merged to the dev branch in fast-forward mode.

    tools for code review

    SonarQube – a tool for static code analysis and calculating the percentage of code covered by tests. It helps us analyze the code of a single pull request. We have installed the Include Code Quality for Bitbucket plugin, which displays the SonarQube code quality check results within the pull request. It prevents us from merging a pull request if the code quality does not meet our team’s standards:

    • There are no errors or vulnerabilities in the new code identified by SonarQube.
    • Test coverage for new code is at least 80%. This requirement encourages us to gradually increase the test coverage of the codebase, as modifying previously written code, we also write tests for it if none exist.

    TeamCity Integration for Bitbucket – a tool to run TeamCity builds from Bitbucket. We use it for:

    • Running tests and initiating SonarQube checks after each commit pushed to Bitbucket.
    • Managing the deployment of our projects to the Atlassian Marketplace and production environments. Although this is not directly related to code review in Bitbucket, it is essential to the overall development process.

    Following these code review guidelines allows us to maintain high-quality code and foster efficient collaboration, leading to better, more reliable software and a more productive development environment. Apart from this, we always leave room for improvement and discuss the processes every two months to make the development of our products even more robust and effective.

    Related posts

      How to See User Activity in Bitbucket Data Center

      September 21, 2023
      #Project management#Analytics#How To#Bitbucket
      7 min

      Tracking user activity is essential for maintaining transparency, accountability, and efficient teamwork. As Bitbucket does not provide an opportunity to see a particular user’s contributions, additional tools are needed. One of them is Awesome Graphs for Bitbucket. The app seamlessly integrates into Bitbucket and offers a comprehensive view of invisible engineering activities. With this tool, you can easily track commits, lines of code, and pull requests data on the instance, project, repository, team, and user levels. Let’s dive into how Awesome Graphs helps see user activity in Bitbucket.

      See user activity in Bitbucket over the past year

      The Contribution graph displays the activity of a particular Bitbucket user over the past year. Each square represents the number of commits and pull requests a developer made on a particular day. Below the graph, some key insights are displayed as well as a list of all user’s commits and pull requests with their details.

      bitbucket see user activity

      Switching to the detailed view allows you to check how the developer distributed efforts between different projects and repositories and see a list of their activities on a specific one.

      bitbucket view user activity

      This graph will give you a comprehensive overview of Bitbucket user activity over the past year, along with daily statistics. It highlights not only the key trends but also provides detailed information, helping analyze how a developer allocates their efforts, find patterns in their work, and see their contributions to project development.

      Track recent Bitbucket user activity

      The Activity graph allows you to see recent user contributions to a particular project or repository. By default, it displays commits and pull requests charts with the number of activities made by top contributors. However, you can choose a particular user and see their activities on the project over the selected period. Below the graph, a list of all commits and pull requests with links to Jira issues, hashes, and Change Type lozenges are shown depending on the filters applied.

      track recent user activity
      Here, you can easily track recent users’ activity on a particular project or repository, enhancing transparency and collaboration within your teams.

      Export data using REST API

      To build custom reports and meet particular requirements, Awesome Graphs for Bitbucket provides an opportunity to export user‘s commit, lines of code, or pull request data via REST API. It lets you get general statistics, retrieve all the details, and export data to a CSV file. Here is an example of the curl command to get a list of commits of a particular user, including commits made by the user’s aliases:

      curl -X GET -u username:password "https://bitbucket.your-company-name.com/rest/awesome-graphs-api/latest/users/{userSlug}/commits"

      This is what the response will look like:

      {
        "values": [
          {
            "user": {
              "emailAddress": "yorlov@stiltsoft.com",
              "displayName": "Administrator",
              "name": "admin"
            },
            "author": {
              "displayName": "admin",
              "emailAddress": "yorlov@stiltsoft.com"
            },
            "authorTimestamp": "2023-03-05T22:58:18Z",
            "linesOfCode": {
              "added": 1,
              "deleted": 0
            },
            "parents": [],
            "repository": {
              "slug": "Commit Hook",
              "name": "commit-hook",
              "project": {
                "key": "TESTCONTAINERS",
                "name": "Testcontainers",
                "type": "NORMAL"
              }
            },
            "id": "9f2e24a147bb8f5a5a3d10b692703cc5784df8b5"
          },
          {
            "author": {
              "displayName": "avoronova",
              "emailAddress": "avoronova@stiltsoft.com"
            },
            "authorTimestamp": "2023-03-05T22:58:18Z",
            "linesOfCode": {
              "added": 2,
              "deleted": 2
            },
            "parents": [
              {
                "id": "06572e813597bc7d77c8"
              }
            ],
            "repository": {
              "slug": "Awesome Graphs for Bitbucket Server",
              "name": "awesome-graphs-for-bitbucket-server",
              "project": {
                "key": "AWEGRAPHS",
                "name": "Awesome Graphs",
                "type": "NORMAL"
              }
            },
            "id": "295760238d83b84647ae4c10ce16f13fa4d24672"
          }
        ],
        "isLastPage": false,
        "nextPageStart": 2,
        "start": 0,
        "size": 2,
        "limit": 2
      }
      

      You can find more information about the Export feature in our documentation. Awesome Graphs’ users can access the in-app documentation through the Export menu in the top-right corner of the People page.

      Apart from this, Awesome Graphs allows you to see the following data on a user level:

      • dynamics of commit or pull request activity
      • total number of commits or pull requests made or total number of lines of code added and deleted over a particular period
      • activity in the code review process

      Thus, seamlessly integrating with Bitbucket, Awesome Graphs provides three easy ways to see user activity in Bitbucket and get a comprehensive view of their contributions, enabling an understanding of personal and team efforts, making informed decisions, and enhancing overall project success.

      Related posts

        Cycle Time vs Lead Time: Optimizing Software Development

        July 20, 2023
        #Analytics#Bitbucket
        8 min

        The terms Cycle Time and Lead Time are used frequently in project management and software development. While they may seem interchangeable, they represent distinct concepts and focus on different aspects. Understanding the differences between Cycle Time and Lead Time is vital for effectively managing projects and optimizing processes. This article highlights the differences between Cycle Time and Lead Time, their importance for engineering teams, and how they can be measured using tools like Awesome Graphs for Bitbucket.

        What is Cycle Time?

        Cycle Time refers to how long a person or team completes a work item from beginning to end. In software development, Cycle Time usually refers to the time from the developer’s first commit in a pull request to its deployment and equates to one of the key DORA metrics – Lead Time for Changes. Apart from that, Cycle Time is commonly divided into four phases:

        • Time to Open – from the first commit to the pull request opening
        • Pickup Time – from the pull request opening to when the review begins
        • Review Time – from when the review begins to when the pull request is merged
        • Time to Deploy – from when the pull request is merged to when it is deployed

        These phases may differ slightly depending on the calculation method.

        What is Lead Time?

        Lead Time comes from Lean manufacturing and refers to the time between placing an order and receiving the product. In software development, Lead Time represents the total duration from the moment a client makes a request until the requested work is completed and delivered. It includes not only the time spent working on the task but also any waiting time or delays that occur during the entire workflow. So Lead Time provides insights into customer satisfaction, project management, and the identification of inefficiencies in the overall delivery process.

        cycle time vs lead time

        Cycle Time vs Lead Time: Key Differences

        What they measure:

        • Cycle Time measures how long it takes for a task to move from the “in progress” to the “completed” stage. It focuses on the active working time, including coding, review, and deployment phases.
        • Lead Time measures how long it takes to complete a task from the backlog. It includes the entire workflow, from when the client’s request is made until it is delivered.

        Who can influence:

        • Cycle Time is primarily influenced by the engineering team’s workflow and efficiency. It depends on the teams’ productivity and their ability to complete tasks promptly.
        • Lead Time depends not only on software development teams but also on product managers and business stakeholders who prioritize and allocate tasks.

        How to measure them:

        • Cycle Time can be measured automatically using tools for tracking engineering activities like Awesome Graphs for Bitbucket. It helps examine four key phases of the Cycle Time and identify areas that need attention.
        • Measuring Lead Time is much more complicated and less standardized. While some tickets in backlog may wait long before being addressed or never be worked on, others are rapidly processed. Thus including all these tickets in Lead Time calculations can lead to inaccuracies and inflated metrics.

        Why use them:

        • Cycle Time is a valuable metric for engineering teams to optimize their day-to-day operations and measure their productivity. By tracking Cycle Time, teams can identify inefficiencies in their development workflow, streamline processes, and reduce Lead Time.
        • Lead Time is essential for understanding the software development process’s responsiveness and customer satisfaction. It helps organizations set realistic expectations for their customers and stakeholders.

        How to find Cycle Time in Bitbucket

        As can be seen, Cycle Time and Lead Time are closely related and play an important role in understanding the speed and efficiency of the development process. However, the Lead Time metric is beyond the complete control of engineering teams and does not fully reflect their performance. Conversely, Cycle Time can be measured more precisely and serve to enhance the engineering process and improve developers’ productivity. Moreover, influencing Cycle Time and its four phases can significantly change Lead Time. That’s why Git repository tracking tools like Awesome Graphs for Bitbucket consider Cycle Time as a more accurate measure of software development team performance.

        Awesome Graphs is an easy-to-use tool that seamlessly integrates into Bitbucket and transforms invisible engineering activities into actionable insights. It helps IT managers and their teams better understand the development process and effectively monitor team productivity, including Cycle Time.

        The Cycle Time column extends the Bitbucket pull requests page and allows you to monitor whether the development process is getting faster or slower.

        Cycle time in Bitbucket

        Apart from this, you can click on a value in the Cycle Time column against a particular pull request to see the breakdown and analyze each cycle phase.

        cycle time breakdown

        Cycle Time is a crucial metric in software development, directly impacting efficiency and productivity. With Cycle Time as a guiding measure, software development teams can continuously improve their processes and enhance overall performance. Awesome Graphs for Bitbucket enables teams to measure and track Cycle Time effectively. With this tool, engineering teams can identify bottlenecks, improve their processes, and deliver high-quality products faster.

        Start your free trial and monitor your development process effortlessly.

        Related posts

          Enhance Developer Productivity with the SPACE Framework in Bitbucket

          June 13, 2023
          #Reporting#Analytics#Bitbucket
          11 min

          Measuring developer productivity is a challenging task that goes beyond individual skills and the number of lines of code written. It encompasses a wide range of factors, and relying solely on a single metric or activity data cannot accurately reflect it. The SPACE framework was introduced to capture the main factors influencing developer productivity. It recognizes that productivity extends individual performance and metrics and offers five key dimensions for a comprehensive view.

          In this article, we’ll cover what the SPACE framework is, explore its five key dimensions, and see how to implement it in Bitbucket.

          What is the SPACE framework?

          The SPACE framework is a complex approach to a comprehensive understanding of developer productivity. It was presented by a group of researchers from Microsoft, GitHub, and the University of Victoria and acknowledges that productivity extends beyond individual performance and metrics.

          This framework helps organizations measure and optimize developers’ productivity by considering five key dimensions:

          • Satisfaction and well-being
          • Performance
          • Activity
          • Communication and collaboration
          • Efficiency and flow.

          All these dimensions should be considered on three levels: Individual, team, and system.

          SPACE metrics

          Source: The SPACE of Developer Productivity.

          Let’s explore these dimensions in more detail.

          SPACE dimensions of developer productivity

          Satisfaction and well-being

          The level of developer satisfaction refers to how satisfied they feel with their work, team, equipment, and corporate culture. The level of well-being refers to their health, happiness, and work impact. Measuring satisfaction and well-being not only helps understand productivity but can also indicate potential burnout or poor performance. By monitoring these aspects, organizations can take measures like “mental health” days or extra vacation days to prevent burnout and improve overall well-being.

          Surveys can often be very helpful in measuring the well-being and satisfaction of your employees.

          Examples of metrics:

          • Employee satisfaction
          • Perception of code reviews
          • Satisfaction with engineering systems

          Performance

          Measuring software developers’ performance is challenging due to the difficulty in directly attributing individual contributions to product outcomes. A high quantity of code does not necessarily mean high-quality code, and neither does customer satisfaction always correlate with positive business outcomes. Therefore, evaluating performance in terms of outcomes rather than outputs is often a better approach. In the most simplistic view, software developer performance could be summarized as “Did the code written by the developer perform as expected?”

          Examples of metrics:

          • Code review velocity
          • Story points shipped
          • Reliability
          • Feature usage
          • Customer satisfaction

          Activity

          Activity, measured as the count of actions or outputs, gives useful but limited insights into productivity, engineering systems, and team performance. However, developers engage in a wide range of complex and diverse activities that are difficult to measure comprehensively. While activity metrics can provide some understanding, they should always be combined with other dimensions to assess developer productivity. These metrics serve as starting points and must be customized according to organizational needs and development processes.

          Example of metrics:

          • Number of code reviews completed
          • Coding time
          • # commits or lines of code
          • Frequency of deployments

          Communication and collaboration

          Effective communication and collaboration are vital for successful project development. Collaboration within and between teams, supported by high transparency and awareness of team member activities, dramatically impacts productivity. Informed teams tend to be more effective as they work on the right problems, generate innovative ideas, and make better decisions.

          Example of metrics:

          • PR merge times
          • Quality of code reviews
          • Knowledge sharing
          • Onboarding time

          Efficiency and flow

          Efficiency and flow refer to how quickly progress can be made with minimal interruptions or delays. Individual efficiency is achieved by setting boundaries, reducing distractions, and optimizing software development flow. Team and system efficiency embodies the process of transforming software concepts into product deliveries while eliminating any delays or handoffs in this flow. Team flow can be monitored using DORA metrics such as deployment frequency or lead time for changes.

          Example of metrics:

          • Code review timing
          • Lack of interruptions
          • Number of handoffs
          • Lead time for changes

          How to use the SPACE metrics

          Here are the best practices on how effectively implement the SPACE framework:

          1. Choose multiple metrics. To obtain a holistic view of developer productivity, it is important to include several metrics from multiple dimensions. The recommended number of dimensions is at least three. For example, if you track an activity metric, add metrics from other dimensions, perhaps performance and efficiency & flow. Avoid focusing on a single aspect and consider the broader impact on the entire system.
          2. Add perceptual measures. Include survey data to gain a comprehensive understanding of developers’ productivity. Perceptions provide valuable insights that cannot be obtained solely from system behavior.
          3. Avoid excessive metrics. Capturing too many metrics can lead to confusion and decreased motivation. Select a few metrics to maintain focus and set achievable improvement goals.
          4. Set important metrics. Choose metrics that align with organizational values and goals as they affect decision-making and individual behavior and indicate what is important.
          5. Protect privacy. When reporting metrics, respect developer privacy and share only anonymized and aggregated results. However, individual productivity analysis may be useful for developers, as it will assist them in optimizing their work and identifying inefficiencies.
          6. Consider norms and biases. Take into account that no metric is perfect, and some may have limitations or biases like cultural aspects or parental leave for metrics counted over a year. Consider these factors and the broader context when interpreting chosen metrics.

          How to Implement the SPACE Framework in Bitbucket

          Implementing the SPACE framework in Bitbucket can be facilitated using Awesome Graphs for Bitbucket. It is an on-prem solution that transforms invisible engineering activities into actionable insights and reports empowering managers and their teams to gain a deeper understanding of the development process and drive continuous improvement.

          Awesome Graphs seamlessly integrates into Bitbucket and provides the following capabilities:

          • Tracking commits, pull requests, and lines of code. You can monitor the number of commits or pull requests on the instance, team, or user levels, analyze and compare progress to past sprints or quarters, and see the engineering contribution for each repo and project. Thus, you can easily track, for instance, activity metrics from the SPACE framework, such as commits or lines of code.
          • Analyzing code review process. Awesome Graphs shows how the code review process is going. You can analyze PR merge times, see the quality of code reviews, find the most active reviewers, and identify areas for improvement. It helps in monitoring performance as well as communication and collaboration metrics.
          • Exporting data to a CSV file or via REST API. You can retrieve raw data about commits, lines of code, or pull requests at different levels and blend it with information from other applications to gain deeper insights. This feature allows you to build custom reports and track metrics aligned with your organization’s values and goals.

          The SPACE framework offers a holistic approach to tracking the development process, empowering engineering managers and their teams with valuable insights into developer productivity. Awesome Graphs opens up opportunities to effortlessly implement this framework in your Bitbucket and effectively measure and improve teams’ productivity.

          Start your free trial and reach a new level of visibility and efficiency in your development process and productivity.

          How to Find Data in Bitbucket to Monitor IT Compliance Standards

          January 10, 2023
          #Bitbucket#Reporting#How To
          20 min

          Compliance management is essential for businesses that provide financial services and deal with personal information. Banks, insurance companies, and other financial institutions must adhere to a range of external as well as internal IT compliance standards and policies to ensure data integrity, mitigate security risks in product development and avoid reputational damage caused by cyberattacks. Moreover, these regulatory requirements are constantly updating and changing, making it challenging to stay on top of compliance.

          That’s why almost every financial organization has a dedicated compliance person or team who deals with IT controls, supports audits, and manages regulatory risks. However, as engineering data is scattered across different tools and some don’t provide aggregated information, compliance officers face difficulties finding, collecting, and reporting on the data needed to pass audits. Sometimes they even have to build custom tooling to ensure the organization’s security and compliance posture.

          With all that in mind, we decided to show how to quickly find data in Bitbucket to track several most common violations of secure code development using Awesome Graphs for Bitbucket and comply with IT standards. Here they are:

          1. The author of the pull request approved their own pull request
          2. The committers of the pull request approved the pull request they contributed to
          3. The pull request was merged with fewer than two approvals
          4. The pull request was merged without the reviewer
          5. Unauthorized people merged or approved a pull request

          How to get data with Awesome Graphs for Bitbucket

          First, let’s explore features of Awesome Graphs that help find information needed to comply with IT controls and meet regulatory requirements.

          Graphs & Reports

          Awesome Graphs provides a set of commit and pull request graphs and reports to show what is happening inside the project development. They help analyze activity in repositories and projects as well as track all changes.

          To view graphs and reports in Bitbucket, you need to go to the project or repository you’d like to review and click on the Reports or Graphs icon in the navigation bar.

          Export to CSV

          Awesome Graphs for Bitbucket also enables users to export data to CSV directly from Bitbucket. It can be done in several ways. In the first option, you need to go to the People page and choose CSV in the Export menu at the top-right corner.

          The outcome will be a list of pull requests or commits with detailed information helpful for audit or compliance teams.

          Export data to CSV to find necessary data and meet IT compliance standards

          Alternatively, the Awesome Graphs REST API can be used to export data to a CSV file. To find the documentation, you need to go to the People page, choose REST API in the Export menu, or visit our documentation website.

          Export via REST API

          As mentioned above, Awesome Graphs provides an opportunity to export raw data about commits, lines of code, and pull requests via REST API. You can retrieve data on the global, project, or repository level and get three types of outputs:

          • List of PRs or commits with detailed information
          • Export of data to a CSV file
          • Raw statistics with the number of PRs or commits

          It gives access to resources via URI paths, uses JSON as its communication format, and the standard HTTP methods like GET, PUT, POST, and DELETE.

          For more detailed information, you may refer to our article How to Search for Commits in Bitbucket Server and Data Center or our documentation.

          Below, we’ll show how to use these features of Awesome Graphs to detect the most common violations of secure code development and meet compliance requirements.

          How to check the most common violations with Awesome Graphs for Bitbucket

          The author of the pull request approved their own pull request

          1st option – Quick check using Reports

          To find authors and reviewers of pull requests, you can navigate to the Pie Chart Report, group data by Author in the Statistic type field, and choose a time period or a team if needed.

          As a result, it displays the list of all pull requests with their authors for the selected time span. Click on a particular author and check if they approved (green checkmark) their own pull request.

          2nd option – Export pull request data to CSV

          To check pull requests in bulk or prepare custom reports for audits, you can export them to a CSV file. Here is an example of working with it in Google Sheets, but the same can be done in Excel as well.

          Then use Conditional formatting for the Reviewers’ Names column: Format → Conditional formatting → Format cells if Text contains =C1 (Author Name). Authors who have reviewed their own pull requests will be highlighted, making it easy to find them.

          The committers of the pull request approved the pull request they contributed to

          This information can be obtained using the Awesome Graphs REST API and the standard REST API of Bitbucket. Here is a Python script you can use. It retrieves data on the project level and identifies pull requests where committers approved their contributions.

          import sys
          import requests
          import csv
          
          bitbucket_url = sys.argv[1]  # https://bitbucket.your-company-name.com
          login = sys.argv[2]
          password = sys.argv[3]
          project = sys.argv[4]
          since = sys.argv[5]  # YYYY-MM-DD
          until = sys.argv[6]  # YYYY-MM-DD
          
          s = requests.Session()
          s.auth = (login, password)
          
          
          class PullRequest:
          
              def __init__(self, created, closed, repo_slug, pr_id, title, state, author, reviewers):
                  
                  self.created = created
                  self.closed = closed
                  self.repo_slug = repo_slug
                  self.pr_id = pr_id
                  self.title = title
                  self.state = state
                  self.author = author
                  self.reviewers = reviewers
          
          
          def get_pull_requests():
          
              pull_request_list = []
          
              get_prs_url = bitbucket_url + '/rest/awesome-graphs-api/latest/projects/' + project + '/pull-requests'
          
              is_last_page = False
          
              while not is_last_page:
          
                  response = s.get(get_prs_url, params={'start': len(pull_request_list), 
                                                        'limit': 1000,
                                                        'sinceDate': since, 
                                                        'untilDate': until, 
                                                        'state': 'merged'}).json()
          
                  for pr_details in response['values']:
                      
                      reviewers = []
                      
                      for reviewer in pr_details['reviewers']:
                          reviewers.append(reviewer['user']['name'])
                      
                      created = pr_details['createdDate']
                      closed = pr_details['closedDate']
                      repo_slug = pr_details['toRef']['repository']['slug']
                      pd_id = pr_details['id']
                      title = pr_details['title']
                      state = pr_details['state']
                      author = pr_details['author']['user']['name']
                      
                      pull_request_list.append(PullRequest(created, closed, repo_slug, pd_id, title, state, author, reviewers))
          
                  is_last_page = response['isLastPage']
          
              return pull_request_list
          
          
          def get_pr_committers(pull_request):
              
              committers = []
              
              commits_url = bitbucket_url + '/rest/api/latest/projects/' + project + '/repos/' + pull_request.repo_slug + '/pull-requests/' + str(pull_request.pr_id) + '/commits'
              
              is_last_page = False
          
              while not is_last_page:
          
                  commits_response = s.get(commits_url, params={'start': len(committers), 'limit': 500}).json()
          
                  for commit in commits_response['values']:
                      
                      committer = commit['author']['name']
                      committers.append(committer)
          
                  is_last_page = commits_response['isLastPage']
                  
              committers_wo_duplicates = list(dict.fromkeys(committers))
          
              return committers_wo_duplicates
          
          
          print(f'Collecting a list of pull requests from project {project}')
          
          pr_list = get_pull_requests()
          
          committers_are_reviewers_prs = []
          
          print('Processing the list of pull requests')
          
          for pull_request in pr_list:
          
              committers = get_pr_committers(pull_request)
          
              for committer in committers:
          
                  if committer in pull_request.reviewers:
                      
                      committers_are_reviewers_prs.append(pull_request)
          
          
          with open(f'{project}_pull_requests_{since}_{until}.csv', mode='a', newline='') as report_file:
              
              report_writer = csv.writer(report_file, delimiter=',', quotechar='"', quoting=csv.QUOTE_MINIMAL)
              report_writer.writerow(['created',
                                      'closed',
                                      'project',
                                      'repo_slug',
                                      'pr_id',
                                      'title',
                                      'state',
                                      'author',
                                      'reviewers'])    
          
              for pr in committers_are_reviewers_prs:
          
                  report_writer.writerow([pr.created, 
                                          pr.closed, 
                                          project, 
                                          pr.repo_slug, 
                                          pr.pr_id, 
                                          pr.title, 
                                          pr.state, 
                                          pr.author,
                                          pr.reviewers])
          
          print('The resulting CSV file is saved to the current folder')

          To make this script work, you’ll need to pre-install the requests module. The csv and sys are available in Python out of the box. You need to pass the following arguments to the script when executed:

          • the URL of your Bitbucket,
          • login,
          • password,
          • project key,
          • since date (to include PRs created after),
          • until date (to include PRs created before).

          Here’s an example:

          py script.py https://bitbucket.your-company-name.com login password PRKEY 2020-11-30 2021-02-01

          Once the script’s executed, the resulting file will be saved to the same folder as the script. Following is an example of the response:

          The pull request was merged with fewer than two approvals 

          1st option – Quick check using Reports

          To find the list of pull requests with the reviewers who approved them, use the Pie Chart Report. In the configuration tab in the Statistic type field, select grouping by State, and choose a time period or a team if necessary.

          You can view all merged pull requests with their reviewers below the report by clicking the Merged sector. The reviewers with the green checkmark are those who approved pull requests. You can scroll the list and find merged PRs with fewer than two approvals.

          2nd option – Export pull request data via REST API

          You can get the status of each reviewer using Awesome Graphs REST API. Here is an example to retrieve data on the project level:

          https://bitbucket.your-company-name.com/rest/awesome-graphs-api/latest/projects/{projectKey}/pull-requests?state=merged

          Then you can display this information in Confluence using, for example, Table from JSON macro (a feature of Table Filter and Charts for Confluence) and add a pivot table or export to CSV and apply Conditional formatting in Google Sheets or Excel. Thus, you’ll get a list of pull requests merged with fewer than two approvals.

          Additionally, Bitbucket lets you set up checks for merging pull requests. It’s a list of restrictions that can be imposed to maintain high code quality standards and comply with IT regulatory requirements. You can specify a minimum number of approvals needed to merge pull requests.

          The pull request was merged without the reviewer

          1st option – Quick check using Reports

          To find pull requests merged without reviewers, use the Pie Chart Report. Group data by Reviewer in the Statistic type field and click on the No reviewer slice in the chart. Below the report, you’ll see all pull requests merged without a reviewer.

          2nd option – Export pull request data to CSV

          To check pull requests in bulk or prepare reports for audit or compliance teams, you can export them to a CSV file and apply filters to the State column (choose Merged) and the Reviewers’ Names column (choose Blanks). Thus, you’ll get the list of pull requests that were merged without reviewers.

          Apart from this, there is also an option to retrieve data using REST API with a filter by pull request state. Here is a request example on the project level:

          https://bitbucket.your-company-name.com/rest/awesome-graphs-api/latest/projects/{projectKey}/pull-requests?state=merged

          Unauthorized people merged or approved a pull request

          Logging all changes and restricting access to unauthorized people is one more principle of protecting production code. However, the concept of authorized people may vary depending on the organization, project, or industry requirements. But as was shown above, with Awesome Graphs, you can quickly get a list of individuals who made changes and compare it with those who had the rights.

          It’s also worth noting that Bitbucket has built-in features to control access to code and adhere to regulatory requirements:

          As can be seen, all of the most common violations can be easily identified using Awesome Graphs for Bitbucket. With it, compliance officers can quickly check if all processes comply with IT controls and standards, as well as collect engineering data to ensure the organization’s security posture and facilitate compliance management.

          If you need to meet other IT controls, you can contact our support team, and we’ll share our ideas on how our app may help.

          Related posts