GitLab 23 🦊 Project Analytics, Value Stream Management, and Productivity Metrics - KandZ

⏱️ Estimated read: 10 min | |

A pipeline that runs and a repository that stores code are not, by themselves, a measure of software delivery performance. GitLab provides analytics features that answer the questions that matter to engineering leadership: how long does it take from idea to production, where is the bottleneck in the workflow, and what is the team’s throughput? The exam tests the conceptual model: Value Stream Analytics (VSA) measures the time items spend in each stage of the development lifecycle, the DORA metrics measure deployment performance, and the productivity analytics measure merge request velocity. The critical distinction is between the lifecycle metrics (lead time, cycle time) and the DORA metrics (deployment frequency, lead time for changes, time to restore service, change failure rate). VSA answers “where is the time going?” DORA answers “how well are we delivering?”

Key point: Value Stream Analytics shows the median time spent by issues or merge requests in each development stage. The default stages are Issue, Plan, Code, Test, Review, and Production. The Lead Time is the median time from issue creation to issue closure. The Cycle Time is the median time from the first commit of a linked merge request to issue closure. DORA metrics measure deployment frequency, lead time for changes, time to restore service, and change failure rate. The GraphQL API exposes the VSA metrics for external reporting.

Why project analytics require a specific mental model

The stage-time problem. A development lifecycle is a sequence of stages: an issue is created, it is planned, code is written, tests are run, the merge request is reviewed, and the change is deployed. Each stage takes time. The total time is the sum. VSA measures the median time spent in each stage, which identifies the stage that is the bottleneck. If the “Review” stage takes 5 days and the “Code” stage takes 1 day, the review process is the problem, not the coding .

The lead-time versus cycle-time problem. The Lead Time is the median time from issue creation to issue closure. The Cycle Time is the median time from the first commit of a linked merge request to issue closure. The cycle time is usually shorter than the lead time because the merge request is created after the first commit. The cycle time measures the code-writing and review process. The lead time measures the entire process, including the planning and waiting before the code is written .

The DORA problem. The DORA metrics are a standardized set of four metrics: Deployment Frequency (how often code is deployed to production), Lead Time for Changes (the time from commit to production), Time to Restore Service (the time to recover from a failure), and Change Failure Rate (the percentage of deployments that cause a failure). These metrics are calculated from the deployment data, not the issue data. They require a production environment to be configured .

The tier problem. VSA is available in the Free tier, but the Free tier does not aggregate data; it queries the database directly, and the date range filter is applied to the creation date. The Premium and Ultimate tiers aggregate the data and apply the date range filter to the end event. The custom value streams (the ability to create, edit, and delete stages) are available only in Premium and Ultimate .

The trade-off. VSA is a process metric, not a productivity metric. It measures the system, not the individual. The Productivity Analytics and Contribution Analytics measure individual activity, but they are not the same as VSA. The exam tests the distinction between the process metrics (VSA) and the delivery metrics (DORA), and the stage measurement.

a. Value Stream Analytics and the lifecycle stages

VSA is accessed from the project or group sidebar under Analytics → Value stream. The default stages are Issue, Plan, Code, Test, Review, and Production. The Total time chart shows the average number of days for a development cycle to complete .

The Lead Time and Cycle Time are displayed below the filter results. The Lead Time is the median time from issue creation to issue closure. The Cycle Time is the median time from the first commit of a linked merge request to issue closure .

The date range selector filters items by the event time. The event time is when the selected stage finished for the given item . The filter can be narrowed by author, assignee, label, and milestone .

The Tasks by type chart displays the cumulative number of completed tasks (closed issues and merged merge requests) per day. The chart uses the global page filters .

b. DORA metrics and deployment performance

The DORA metrics are displayed in the VSA page and in the Value Streams Dashboard. The four metrics are:

Metric	Definition
Deployment Frequency	Average number of deployments to production per day
Lead Time for Changes	Time from commit to deployment to production
Time to Restore Service	Time to recover from a production failure
Change Failure Rate	Percentage of deployments that cause a failure

The Deployment Frequency and Lead Time for Changes do not depend on Jira. The Time to Restore Service and Change Failure Rate require the DORA API data, which is available in Premium and Ultimate .

The DORA metrics require a production environment to be configured. The data is filtered based on the environment and the environment tier .

c. Productivity analytics and the GraphQL API

The Productivity Analytics shows the merge request lifecycle, filterable down to the author level. It measures the time from merge request creation to merge, the number of merge requests, and the review time .

The Merge Request Analytics shows the mean time to merge (MTTM), which is the average lifespan of a merge request from creation to merge. It excludes merge requests that are closed or unmerged .

The GraphQL API exposes the VSA metrics for external reporting. The metrics node accepts a timeframe (maximum 180 days) and returns the average, median, and count for each stage . The timeframe is required. The labelNames, milestoneTitle, and assigneeUsernames filters narrow the scope .

group(fullPath: "your-group") {
  valueStreams(id: "your-stream-id") {
    nodes {
      stages(id: "your-stage-id") {
        id
        name
        metrics(timeframe: { start: "2026-09-01", end: "2026-09-30" }) {
          average { value unit }
          median { value unit }
          count { value unit }
        }
      }
    }
  }
}

The Value Streams Dashboard is a customizable dashboard that shows the DORA metrics and the lifecycle metrics in a single view. It is disabled by default and must be enabled in the group settings. The dashboard requires the Reporter role or higher .

Complete Example Session

# ============================================
# PART 1: ACCESS VALUE STREAM ANALYTICS
# ============================================

# Project sidebar → Analytics → Value stream
# The page shows the lifecycle metrics and the stage breakdown.

# ============================================
# PART 2: VIEW LEAD AND CYCLE TIME
# ============================================

# Below the filter results:
# Lead Time: 12 days
# Cycle Time: 4 days
# The difference is the planning and waiting time.

# ============================================
# PART 3: IDENTIFY THE BOTTLENECK
# ============================================

# Hover over each stage:
# Issue: 1 day
# Plan: 2 days
# Code: 3 days
# Test: 1 day
# Review: 5 days
# The "Review" stage is the bottleneck.

# ============================================
# PART 4: FILTER BY DATE RANGE
# ============================================

# Set From: 2026-09-01
# Set To: 2026-09-30
# The metrics are recalculated for the selected period.

# ============================================
# PART 5: VIEW DORA METRICS
# ============================================

# Lifecycle metrics row → Value Streams Dashboard / DORA
# The DORA metrics are displayed.

# ============================================
# PART 6: GRAPHQL API QUERY
# ============================================

# Query the VSA metrics for a stage.
# See the example query in section c.

# ============================================
# PART 7: VIEW PRODUCTIVITY ANALYTICS
# ============================================

# Group sidebar → Analytics → Productivity
# Shows the merge request lifecycle, filterable by author.

# ============================================
# PART 8: VIEW MERGE REQUEST ANALYTICS
# ============================================

# Project sidebar → Analytics → Merge requests
# Shows the mean time to merge (MTTM).

# ============================================
# PART 9: ENABLE VALUE STREAMS DASHBOARD
# ============================================

# Group settings → Analytics → Value Streams Dashboard
# Enable the dashboard.
# The dashboard is available at the group's analytics dashboards page.

The nine parts trace the analytics workflow: access VSA, view lead/cycle time, identify the bottleneck, filter by date, view DORA, query the API, view productivity, view merge request analytics, and enable the dashboard.

Quick Reference

Lifecycle Metrics

Metric	Definition
Lead Time	Median time from issue creation to closure
Cycle Time	Median time from first commit to issue closure
Deploys	Number of successful deployments
Deployment Frequency	Average deployments per day

DORA Metrics

Metric	Definition
Deployment Frequency	Deployments per day
Lead Time for Changes	Commit to production
Time to Restore Service	Recovery time
Change Failure Rate	Failed deployments percentage

VSA Stages

Stage	Measurement
Issue	Issue creation to labeling/milestone
Plan	Labeling to first commit
Code	First commit to merge request creation
Test	Merge request creation to review
Review	Review to merge
Production	Merge to deployment

API

Field	Purpose
`valueStreams`	Configured value streams
`stages`	Stages in a value stream
`metrics`	Average, median, count
`timeframe`	Required, max 180 days

Best Practices

✅ Do This:

metrics(timeframe: { start: "2026-09-01", end: "2026-09-30" })
<!-- Always specify the timeframe -->                 # ✅

# Hover over each stage in VSA
<!-- Identify the bottleneck stage -->               # ✅

# Compare Lead Time and Cycle Time
<!-- The difference is planning/waiting time -->     # ✅

❌ Don’t Do This:

# Assume VSA measures individual productivity
<!-- VSA measures the process, not the person -->    # ❌

# Request metrics without a timeframe
<!-- The API requires the timeframe -->              # ❌

# Ignore the DORA metrics for delivery performance
<!-- DORA is the standard delivery metric -->        # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
VSA data outdated	Background aggregation delay	Reaggregate in the Rails console
Lead time longer than cycle time	Expected; cycle time is narrower	Compare both
DORA metrics empty	No production environment	Configure production environment
API request slow	Requesting all stages at once	Request stage by stage
Custom stages not available	Free tier	Upgrade to Premium/Ultimate

Real-World Examples

1. View VSA

Analytics → Value stream

2. Lead Time

Median time from issue creation to closure

3. Cycle Time

Median time from first commit to issue closure

4. DORA Metrics

Lifecycle metrics row → Value Streams Dashboard / DORA

5. Deployment Frequency

Average deployments per day

6. GraphQL Query

group(fullPath: "group") { valueStreams { nodes { stages { metrics(timeframe: { start: "2026-09-01", end: "2026-09-30" }) { average { value } } } } } }

7. Productivity Analytics

Group → Analytics → Productivity

8. Merge Request Analytics

Project → Analytics → Merge requests

9. Enable Dashboard

Group settings → Analytics → Value Streams Dashboard

10. Filter by Date

From: 2026-09-01, To: 2026-09-30

Visual

VSA Stage Flow

┌──────────────────────────────────────────────┐
│  Issue → Plan → Code → Test → Review → Prod  │
│  1 day   2 days  3 days  1 day  5 days  1 day│
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  Bottleneck: Review (5 days)                 │
└──────────────────────────────────────────────┘

Lead vs Cycle Time

┌──────────────────────────────────────────────┐
│  Issue created ────────────────────────▶ Closed│
│  │                                            │
│  │◀────── Lead Time ────────▶│               │
│  │                           │               │
│  │       First commit ───────▶│               │
│  │                           │               │
│  │◀────── Cycle Time ────────▶│               │
└──────────────────────────────────────────────┘

Summary

Item	Value
VSA location	Analytics → Value stream
Lead Time	Issue creation to closure
Cycle Time	First commit to issue closure
DORA metrics	Deployment frequency, lead time, restore time, failure rate
VSA API	GraphQL `valueStreams`
Timeframe limit	180 days
Custom stages	Premium/Ultimate
Value Streams Dashboard	Group settings → Analytics

Key takeaways:

VSA measures the process, not the person. The lead time and cycle time are median durations for issues and merge requests. The stage breakdown identifies the bottleneck. The Review stage is often the longest, which means the review process is the target for improvement .
The Lead Time is longer than the Cycle Time. The difference is the planning and waiting time before the first commit. The Cycle Time measures the code-writing and review process .
The DORA metrics measure delivery performance. The four metrics are the standard for software delivery. They require a production environment to be configured. The Free tier has limited DORA access; Premium and Ultimate have the full set .
The GraphQL API exposes VSA data. The metrics node requires a timeframe (maximum 180 days). The data can be exported for external reporting .
The Value Streams Dashboard is customizable. It shows the DORA metrics and the lifecycle metrics in a single view. It is disabled by default and must be enabled in the group settings .

Remember: VSA answers “where is the time going?” DORA answers “how well are we delivering?” The Lead Time is the whole process. The Cycle Time is the code process. The stage breakdown is the diagnostic. The GraphQL API is the export. The exam tests the metrics and the distinction between the process metrics and the delivery metrics.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!