Arrival rate

The rate work crosses the commitment point and enters the delivery system. If five tickets move from the options backlog into committed work each week, the arrival rate is five items per week.

Blocked

A committed item that cannot progress because it needs a dependency, decision, access, or another team. A pull request waiting for production credentials is blocked work and remains part of WIP.

Class of service

An explicit policy for handling work with a particular urgency or risk. A production incident may use an expedite policy, while a routine dependency update follows the standard queue.

Constraint

The stage whose available rate limits the output of the whole system. When code review can clear fewer pull requests than developers submit, review sets the delivery ceiling and a queue forms in front of it.

Cost of delay

The value lost for each unit of time that work remains undelivered. A compliance change tied to a fixed deadline has a different cost profile from a feature that earns a steady amount each week after release.

Cumulative flow diagram

A chart of the accumulated number of items that have reached each workflow stage over time. The vertical distance between two stage lines shows the WIP between them; a widening band shows a growing queue.

Cycle time

The total elapsed time from commitment to delivery. It includes active development, review, blocked time, and every period the ticket spends waiting between those activities.

Flow efficiency

Touch time divided by cycle time. A ticket receiving two days of active work during a ten-day cycle has 20% flow efficiency; the remaining time was spent waiting or blocked.

Little's Law

The relationship between average WIP, throughput, and cycle time in a stable system: WIP equals throughput multiplied by cycle time. At a fixed delivery rate, lowering WIP lowers average cycle time.

Probabilistic forecast

A delivery range expressed with confidence levels and built from observed throughput or cycle-time data. A forecast might say that 30 tickets have an 85% chance of finishing within six weeks.

Pull

A way of starting work when the next stage has capacity. A developer takes the next ticket after a WIP slot opens, keeping new starts tied to the system's ability to finish.

Queue

Work waiting for the next action. Pull requests awaiting a reviewer form a queue even when the board labels them In Review.

Throughput

The rate completed work leaves the system, measured as items per unit of time. Count tickets when they reach Done or production, using the same exit point for every reporting period.

Touch time

The time someone is actively working on an item. Writing code and reviewing a pull request contribute touch time; waiting overnight for review does not.

Utilisation

The share of available capacity demanded from a person or stage. A reviewer able to clear four pull requests per day is near full utilisation when demand also averages four, leaving little room for variation.

Variability

The spread in when work arrives or how long it takes. A burst before a release window creates arrival variability; mixing one-line fixes with database migrations creates work-size variability.

Work in progress (WIP)

All committed work that has started but has not reached the delivery point. Tickets in development and pull requests waiting for review both count as WIP.

WIP limit

An explicit maximum for work allowed in a stage or across the system. When the development limit is full, the team finishes or unblocks an existing ticket before starting another.

Work item type

A category of work with a characteristic route through the delivery system. A feature may need design and formal testing, while a hotfix follows a shorter emergency path.