In A Nutshell

Taking measurements of the team’s Rate of Delivery provides essential information that the team can use to understand whether it is meeting its stakeholders’ expectations - as well as its own ambitions. If the team decides that it needs to improve its rate of delivery, the data can help the team to establish new goals and to choose experimental improvements that may help it deliver on those new goals.

Common Measures of Rate of Delivery

  • is the number of work items that have been blocked from making progress. Teams that use story points may measure this as Blocked Story Point Count.

  • represents the time between a work item being blocked and the completion of activity to unblock the work item. Blocked Time represents unproductive time and it decreases our Flow Efficiency.

  • shows the percentage of time performing useful work on a work item as a proportion of the work items Lead Time:

    flowEfficiency = 100 × (cycleTime - blockedTime) ÷ leadTime

  • a measure of how long it takes for a request from the customer to be made fully available for use. Its components are: Dwell Time - time from entry to the start of work; Cycle Time - time from start to completion of work by the team; Shelf Time - time from completion until available for use.

  • is the number of work items completed in a unit of time. If a Scrum team counts cards rather than using story points, its Throughput is the same as its Velocity

  • the count of the number of story points completed in a sprint. Commonly used by Scrum teams, Velocity is related to Throughput. If the team counts stories rather than using story points then its Velocity is equal to its Throughput.

  • for Work In Progress is the number of days since the work item was started. Analogous to the Cycle Time component of Lead Time, but measured for WIP items rather than completed items.Item description

  • count the number of work items that have been started by the team but that are not yet completed. Work in Progress (WIP) represents investment in work that is not yet capable of creating value. In Scrum rigorous teams will have zero WIP at the end of each sprint. In Kanban there are strict WIP limits on each work stage. Work cannot progress into a stage if its WIP limit is exceeded.

DORA Metrics of Delivery

DORA metrics are used by organisations who practice DevOps. For each of the DORA metrics, a scale of results is provided that allows organisations to be categorised in 4 groups between Elite Performers and Low Performers.

  • what proportion of changes to production or release to end users results in degraded service? Ranging from 0-15% for Elite Performers to 16-30% for Poor Performers.

  • how often can a team deploy code to production or release to end users? From Elite Performers deploying on demand to Poor Performers deploying once per month or less frequently.

  • the time taken for committed changes to be running in production or released to users. Equivalent to the shelf time component of Lead Time. Elite Performers less than one day and up to 6 months for Poor Performers.