Linear Analytics

Linear Analytics gives teams data-driven insight into how work is actually progressing. Instead of guessing whether the team is getting faster or slower, analytics surfaces patterns, trends, and velocity data you can act on. Managers use analytics for planning. Team leads use it for identifying bottlenecks. Engineers use it to understand their own throughput.

Access Analytics

Click Analytics in the left sidebar. By default, the analytics dashboard shows data for your current team. Use the team selector at the top to switch between teams. Most metrics update in real time as issues are created, moved, and closed.

Key Metrics Explained

Metric	What It Measures	Why It Matters
Velocity	Estimate points completed per cycle	Predicts how much work fits in a future cycle
Cycle Completion Rate	Percentage of planned issues closed each cycle	Shows if the team over-commits or under-commits
Lead Time	Time from issue creation to issue closure	Measures total time work takes from start to done
Cycle Time	Time from "In Progress" to "Done"	Measures actual development speed once work starts
Throughput	Number of issues closed per week or cycle	Shows raw output volume over time
Burndown	Remaining work vs time left in a cycle	Predicts whether the cycle goal will be met
Scope Creep	Issues added to a cycle after it started	Identifies unplanned work that disrupts commitments

Velocity Chart

Velocity is the most commonly tracked metric in agile teams. It shows how many estimate points the team completed across past cycles.

VELOCITY CHART (Estimate Points per Cycle)

Points
  40 │
  35 │        ▓▓
  30 │  ▓▓    ▓▓    ▓▓
  25 │  ▓▓    ▓▓    ▓▓    ▓▓
  20 │  ▓▓    ▓▓    ▓▓    ▓▓    ▓▓
  15 │  ▓▓    ▓▓    ▓▓    ▓▓    ▓▓
     └──────────────────────────────
         S20   S21   S22   S23   S24
              Sprint (Cycle)

Average velocity: 28 points per cycle
Use this average to plan the next cycle's capacity.

Burndown Chart

The burndown chart tracks remaining work inside an active cycle. The X axis shows days of the cycle. The Y axis shows remaining issues or points. The ideal line shows the pace needed to finish on time. The actual line shows what's really happening.

CYCLE BURNDOWN CHART

Remaining
Issues
  14 │ ●
  12 │    ●
  10 │ ─ ─ ─ ─● ─ ─         ← Ideal line (target pace)
   8 │             ●
   6 │                ●
   4 │                   ●
   2 │                      ●
   0 │                         ●
     └──────────────────────────────
       Day1  3  5  7  9  11  13 (End)

  ● Actual completion
  ─ Ideal pace
  Result: Team finished slightly ahead of pace — good sign

Lead Time vs Cycle Time

These two metrics are often confused. Understanding the difference is important for diagnosing the right problems.

ISSUE TIMELINE

Jun 1: Issue created (ENG-77 filed as a bug)
         │
         │  ← This gap = waiting time (triage, planning, assignment)
         │
Jun 8: Work begins (moved to In Progress)
         │
         │  ← This gap = CYCLE TIME (active development)
         │
Jun 11: Issue closed (Done)
         │
         └─────────────────────────────────────────
         
Lead Time  = Jun 1 → Jun 11 = 10 days (creation to done)
Cycle Time = Jun 8 → Jun 11 = 3 days  (started to done)

High lead time with low cycle time means work sits in the queue too long before anyone starts. The fix is better triage and faster assignment, not faster development.

Analytics by Assignee

The analytics dashboard can break down metrics by individual team member. This shows each person's throughput, average cycle time, and number of issues completed per period.

Use this view carefully. The goal is to understand workload distribution, not to rank team members. A lower throughput number might mean someone worked on fewer, larger issues — not that they worked less.

Member	Issues Closed (This Cycle)	Avg Cycle Time	Points Completed
Alice	8	1.5 days	18
Bob	4	3.2 days	22
Carlos	6	2.1 days	14

Using Analytics for Cycle Planning

Use analytics before planning each new cycle to answer three questions:

What is our average velocity? Use the last 3–5 cycles as the baseline. Only commit to work at or below this average.
Did we over-commit last cycle? A carry-over rate above 20% means the team took on too much. Reduce the next cycle's planned load.
Are cycle times increasing? Rising average cycle time signals growing complexity, unclear requirements, or team bottlenecks to investigate.

Previous lessons

Back to courses

Next lessons