📊 DORA and Flow Metrics

📊 DORA and Flow Metrics

DORA stands for DevOps Research and Assessment. It is a widely used way to measure how effectively a software team delivers changes to production.

The four core DORA metrics are:

1. Deployment Frequency
2. Lead Time for Changes
3. Change Failure Rate
4. Time to Restore Service (MTTR)

You specifically mentioned lead time, cycle time, deployment frequency, and MTTR. Cycle time is a useful flow metric, but it is not one of the four core DORA metrics.

---

1. ⏱️ Lead Time for Changes

Lead time measures how long it takes for a change to go from the point where it is committed to the point where it is successfully deployed to production.

Example:

Developer writes code
       ↓
Code committed
       ↓
Pull Request
       ↓
Code review
       ↓
Build & Tests
       ↓
Production Deployment

If code is committed on Monday at 10 AM and deployed on Wednesday at 10 AM:

Lead Time = 48 hours

Why it matters

A shorter lead time generally means the organization can deliver customer value faster.

Current Lead Time = 5 days
Target Lead Time  = 2 days

The team should investigate what is causing the remaining 3 days:

• Code reviews
• Testing
• Approval processes
• Deployment queues
• Manual activities
• Environment availability

---

2. 🔄 Cycle Time

Cycle time measures how long work takes from the point when the team actually starts working on it until it is completed.

For example:

Ticket enters backlog
        ↓
     Waiting
        ↓
Developer starts work
        ↓
Coding
        ↓
Testing
        ↓
Completed

If development starts Monday and the feature is completed Wednesday:

Cycle Time = 2 days

Lead Time vs Cycle Time

This distinction is important:

                LEAD TIME
<------------------------------------>

Backlog → Waiting → Development → Testing → Production
                    <---------------->
                       CYCLE TIME

Lead Time includes waiting before work starts and the time until production delivery.

Cycle Time focuses on the active work period.

---

3. 🚀 Deployment Frequency

Deployment Frequency measures how frequently an organization successfully deploys changes to production.

Example:

Monday     → 2 deployments
Tuesday    → 1 deployment
Wednesday  → 3 deployments
Thursday   → 2 deployments
Friday     → 2 deployments

Total:

10 deployments / 5 days = 2 deployments per day

A team might have a target such as:

Baseline:  1 deployment/week
Target:    3 deployments/week

Higher frequency can indicate that the team is able to deliver smaller changes more regularly.

However, more deployments are not automatically better. The deployments should also be safe and successful.

---

4. 🛠️ MTTR — Mean Time to Restore

MTTR measures how long it takes to restore normal service after a production failure or incident.

Example:

10:00 AM → Production issue detected
10:15 AM → Team starts investigation
10:45 AM → Root cause identified
11:00 AM → Fix deployed
11:20 AM → Service restored

MTTR = 80 minutes

The goal is generally to reduce MTTR.

For example:

Baseline MTTR = 4 hours
Target MTTR   = 1 hour

Ways to reduce MTTR include:

• Better monitoring
• Automated alerts
• Faster rollback
• Feature flags
• Automated deployments
• Good logging
• Distributed tracing
• Runbooks
• Incident-response procedures

---

📈 Baseline vs Target Tracking

This is one of the most useful ways to use these metrics.

Baseline = Where you are today.

Target = Where you want to be.

You measure the baseline first, set realistic targets, and then track progress over time.

Example

Suppose a team collects its current data:

Metric	Baseline	Target
Lead Time	5 days	2 days
Cycle Time	3 days	1.5 days
Deployment Frequency	1/week	3/week
MTTR	4 hours	1 hour

Then track the metrics every week.

📊 A Practical Tracking Dashboard

A DevOps team could maintain something like:

Metric	Baseline	Current	Target	Direction
Lead Time	5 days	2.8 days	2 days	↓
Cycle Time	3 days	1.8 days	1.5 days	↓
Deployment Frequency	1/week	2/week	3/week	↑
MTTR	4 hrs	1.6 hrs	1 hr	↓

Here:

• ↓ is good for Lead Time, Cycle Time and MTTR.
• ↑ is generally good for Deployment Frequency.
• Baseline tells you where you started.
• Current tells you where you are now.
• Target tells you where you want to go.

---

🔗 How the Metrics Work Together

Consider a team with:

High Lead Time
      ↓
Changes take a long time to reach production
      ↓
Low Deployment Frequency
      ↓
Large batches of changes
      ↓
Higher risk when something fails
      ↓
Longer recovery
      ↓
High MTTR

The goal is to create a healthier flow:

Small changes
     ↓
Fast development
     ↓
Fast testing
     ↓
Frequent deployments
     ↓
Smaller production changes
     ↓
Easier troubleshooting / rollback
     ↓
Lower MTTR

💡 In simple terms

Lead Time: How long from code change to production?

Cycle Time: How long from starting the work to finishing it?

Deployment Frequency: How often do we deploy?

MTTR: How quickly do we recover when production breaks?

Baseline vs Target: Where are we now, and where do we want to be?

One important addition: if you're building a complete DORA dashboard, include Change Failure Rate as well, because it is the fourth core DORA metric alongside deployment frequency, lead time for changes, and time to restore service.