Oobeya Docs
  • GETTING STARTED
    • Welcome to Oobeya!
    • Get Started with Oobeya
    • Playground: Live Demo
    • Oobeya Quick Onboarding Guide
  • TEAM INSIGHTS & SYMPTOMS
    • Symptoms Catalog
      • S1- Recurring high rework rate
      • S2- Recurring high cognitive load
      • S3- High weekend activity
      • S4 - High Code Review Time
      • S6- High technical debt on Sonar
      • S7- High vulnerabilities on Sonar
      • S8- High code quality bugs on Sonar
      • S9 - Unreviewed Pull Requests
      • S10 - Lightning Pull Requests
      • S11 - Oversize Pull Requests
      • S12- High Lead Time For Changes (DORA)
      • S13- Low Deployment Frequency (DORA)
      • S14- High Change Failure Rate (DORA)
  • SECURITY
    • 🔐Security at Oobeya
    • Oobeya Managed SaaS
  • INSTALLATION
    • 🐳Oobeya Docker Installation Tutorial & Requirements
    • 🐳Oobeya Version Upgrade For the docker-compose Installations
    • 🐳HTTPS Configuration For Docker Installations
  • PRODUCT DOCS
    • ⭐Oobeya Release Notes
      • 🎁Oobeya 2024 Q1 - Release Notes
      • 🎁Oobeya 2023 Q4 - Release Notes
      • 🎁Oobeya 2023 Q3 - Release Notes
      • 🎁Oobeya 2023 Q2 - Release Notes
      • 🎁Oobeya 2023 Q1 - Release Notes
      • 🎁Oobeya Nov & Dec '22 Updates
      • 🎁Oobeya September 2022 Updates
      • 🎁Oobeya August 2022 Updates
      • 🎁Oobeya July 2022 Updates
      • 🎁Oobeya June 2022 Updates
      • 🎁Oobeya Apr & May 2022 Updates
      • 🎁Oobeya March 2022 Updates
      • 🎁Oobeya Feb 2022 Updates
      • 🎁Oobeya Jan 2022 Updates
      • OOBEYA-2.0.8 - Release Notes
      • OOBEYA-2.0.4 - Release Notes
      • OOBEYA-2.0.0
      • OOBEYA-1.4.6
      • QAD-1.0 - 1.4
    • ▶️Product Tour
    • ❇️Metrics List
    • ☀️Developer Experience Metrics
  • INTEGRATIONS
    • Integration Catalog
      • SCM & CI/CD Integrations
        • Azure DevOps Integration
        • Bitbucket Cloud Integration
        • Bitbucket Server Integration
        • GitHub Integration
        • Step-by-Step Integration Instructions for the Oobeya GitHub Application
        • GitLab Integration
        • Jenkins & Cloudbees Integration
        • Octopus Deploy Integration
        • TeamCity Integration
      • Quality & Security Integrations
        • SonarQube Integration
        • SonarQube Cloud Integration
        • Veracode Integration
      • Project Management Integrations
        • Jira Cloud Integration
        • Jira Server Integration
      • APM / Monitoring Integrations
        • AppDynamics Integration
        • Azure Application Insights Integration
        • Dynatrace Integration
        • Elastic APM Integration
        • New Relic Integration
        • Sentry Integration
    • Installing An Addon
    • Adding A New Data Source
    • Updating and Deleting Data Sources
  • ADMINISTRATION
    • User Management, Single Sign-On, Auth Settings
      • Microsoft Entra (Azure AD) Integration
      • LDAP / Active Directory Integration
      • Importing a New User From LDAP / Active Directory
      • Bulk User Import in Oobeya Using CSV
      • Adding a New User
      • Deactivating a User
      • Understanding Roles in Oobeya
    • License Management
      • Updating The License Key
  • DEVELOPMENT ANALYTICS - GITWISER
    • Git Analytics - Metric Definitions
      • Coding Impact Score
      • Impact Ratio (team-level)
    • Setting Up Development Analytics And DORA Metrics
    • Git Analytics Exclusions
    • Setting Automated Reanalyze For Gitwiser
    • Deployment Analytics (DORA Metrics)
    • Merging Contributor Accounts
  • DORA Metrics
    • DORA Metrics Introduction
      • Lead Time For Changes (LTC)
      • Deployment Frequency (DF)
      • Change Failure Rate (CFR)
      • Mean Time To Restore Service (MTTR)
    • Failure Detection (For Change Failure Rate & MTTR)
    • How To Calculate DORA Metrics for GitHub
    • Updating Team Scorecard configuration to display DORA Metrics
    • How To Start Deployment Analytics (DORA Metrics) For An Existing Gitwiser Analysis
  • Project Analytics - AgileSpace
    • Agile Analytics - Metric Definitions
    • Agile Board Analytics Intro
    • Starting an Agile Board Analytics
    • Board Overview
    • Sprint Reports
    • Update the Agile Board Analytics
  • QUALITY ANALYTICS
    • Total Code Quality Index (TCQI)
  • Guides
    • Azure DevOps Guides
      • How To Calculate DORA Metrics for Azure DevOps
      • Best practices for integrating Oobeya with Azure DevOps Scrum Boards
  • PROFILES
    • Introduction
    • Adding A Profile
    • Developer Scorecard
    • Adding A Related Account Information To Oobeya Profile
  • Team Health
    • Adding A Team
    • Team Scorecard
    • Project Analytics (Scrum Teams) Widget
  • Test Quality Report Widget
  • CUSTOM DASHBOARDS
    • Adding A New Dashboard
    • Adding A New Widget
    • Updating And Deleting Widgets
    • Adding Jira Sprint Progress Widget
    • Adding Jira Board Metrics Widget (Metrics With JQL)
  • SUPPORT
    • Support Request Workflow
    • Customer Success & Support Guide
Powered by GitBook
On this page
  • Git Analytics - Work Type Metrics
  • 1. New Work
  • 2. Refactor
  • 3. Help Others
  • 4. Churn / Rework
  • Coding Efficiency
  • Impact Score
  • Setting The Threshold For Work Type Calculation

Was this helpful?

  1. DEVELOPMENT ANALYTICS - GITWISER

Git Analytics - Metric Definitions

PreviousUpdating The License KeyNextCoding Impact Score

Last updated 5 months ago

Was this helpful?

Git Analytics - Work Type Metrics

Git Analytics tools analyze all atomic software development activities and generate metrics to help teams better understand the development process.

Oobeya analyzes all commits in a coding repository and runs an algorithm to identify the work type of each code change. These work-type metrics shouldn't be used as a target for development teams, it's just a tool that enables them to identify the signals of their development process. Oobeya leverages these metrics to detect symptoms of the development process. See the related symptoms below:

S1- Recurring high rework rateS2- Recurring high cognitive load

1. New Work

"New work" is a measure of how much new and fresh work has been done in a given period. The interest in new work in organizations depends on the type of product and work (new projects, maintenance projects, transformation, etc.).

For a task to be considered "new work", the code snippets should not replace others, but rather be written from scratch and independently. Lines added as part of an existing change (git hunk) do not count as new work.

2. Refactor

Developing new features and maintaining existing code often requires revisiting old (legacy) code snippets. As codebases age, preserving code and keeping things up to date are critical goals for organizations.

For work in Oobeya to be considered a "Refactor", at least 3 weeks (industry standard) should have passed since the last addition or modification of old work.

In teams with a high refactor rate, managers (Product Owners, Team Leaders, etc.) need to balance such tasks proportionally with new features. Having high technical debt is undesirable, but having a stagnant (unimproved) product is even worse. The code refactor rate is an important indicator of the project's health.

3. Help Others

It is a measure of how much a software developer has helped to maintain and/or fix another developer's recent code (in 3 weeks).

For work in Oobeya to count as "help others", the block of code worked on together should not be older than 3 weeks. (If it's older than 3 weeks, it's considered a refactoring activity).

The Help Others ratio provides insight into the team's collaborative (pair) working culture and knowledge sharing within the team.

4. Churn / Rework

Code complexity, leaving technical debt, or rewriting/deleting code shortly after it is written is considered a natural part of the development process. Engineers often test different solutions, iterate, and investigate a problem.

Churn levels vary among teams, individuals, project types, and where those projects are in the development life cycle. Different individuals and teams may have different levels of churn based on their workflows and the types of projects they are working on (i.e. a new problem, a known issue, a quick fix, etc.).

Tracking the churn value by iteration in Oobeya provides early visibility into issues that arise during development phases (lack of analysis, lack of know-how, high technical debt, workload distribution, etc.).

For a task in Oobeya to be considered Churn/Rework, the changes must be made by the same person and on a block of code no older than 3 weeks. (If it's older than 3 weeks, it's considered a refactor).


Coding Efficiency

Percentage of productive work. It is calculated by the sum of New Work + Refactor + Help Others.

This metric is measured and displayed at different levels (commit level, individual level, team level) in Oobeya. Tracking the Coding Efficiency metric enables early detection of symptoms that arise during development periods and helps team leaders improve the developer experience and reduce friction.

Impact Score

The Impact Score is an approximate measure of how much cognitive load the engineer performed when developing a commit. It is measured and shown at different levels in Oobeya (commit level, individual level, team level).

Oobeya identifies the cognitive load of team members during development cycles by tracking the Impact Score.

Team and individual health symptoms (burnout, overload, etc.) and working practice symptoms (knowledge silos, etc.) are identified by utilizing the Impact Score. See the related symptom below:

S2- Recurring high cognitive load

Setting The Threshold For Work Type Calculation

Oobeya analyzes commit activities by running an algorithm to identify the type of work for each code change. The algorithm's default threshold is 21 days (3 weeks), but users can customize it for their specific use cases. To change the threshold:

  1. Navigate to Administration > Gitwiser & DORA Metrics > Git Analytics.

  2. Set the threshold for Git work type calculation. (Default value: 21 days)

Changing this parameter will delete all commits and reanalyze them. Please note that analyzing all repositories will take time.

Git Analytics Work Types