Get started

Blog

Plandek metric of the week: Delivery Lead Time

Plandek, March 23, 2021

Plandek Metric of the Week: Delivery Lead Time

Metric Definition

Delivery Lead Time (or ‘Lead Time’) is a core agile software delivery metrics (alongside Cycle Time) which tracks an organisation’s ability to delivery software early and often. The concept of Lead Time is borrowed from lean manufacturing.

Lead Time refers to the overall time to deliver an increment of software from initial idea through to deployment to live – i.e. the complete end-to-end software delivery life cycle (SDLC).

Whilst Cycle Time is a subset of the overall delivery time, typically measured as the time from the start of work (development) until deployment to live (traditional Cycle Time) or from code commit to production (sometimes referred to as Code Cycle Time).

A Lead Time can be calculated for any increment of work – e.g. story, task, bug.

The example below shows Lead Time for stories and so relates to the time taken to deliver new features. As the chart shows the total Lead Time is 11 days which is actually very good and represents the time taken for a ticket (story) to leave the backlog until deployment to live.

Example software delivery Lead Time summary chart – Plandek Value Delivery Efficiency dashboard

 

Example Lead Time status review chart – Plandek Value Delivery Efficiency dashboard

 

As shown in the expanded view of Lead Time in the Lead Time Status Review chart above, analysis of Lead Time should become an integral part of effective agile software delivery.

The chart shows the active and inactive status groups and the time stories spend in each status across the total 11.3 day Lead Time.

If ticket statuses have been sensibly defined in the issue tracking (workflow management) tool such as Jira – then delivery Team Leads and

Delivery Managers can use Lead Time analysis to see where tickets are getting ‘stuck’ in the process.

In the example above, the inactive statuses such as ‘Ready for Development’ account for a relatively large proportion of the overall Lead Time (5.6 days), hence there is friction in the process and there is scope to reduce the overall Lead Time and thereby increase software delivery velocity.

Related metrics

Lead Time is often used in conjunction with other flow metrics such as Cycle Time and Flow Efficiency. Similar to Lead Time, Flow

Efficiency analyses in more detail the flow of work throughout the end-to-end delivery lifecycle, and reflects the proportion of time that a ticket is actively being worked on by the team versus the time it is stalled in some form of a queueing state (e.g. To Do, Pending QA, Pending Sign-off). In other words, it represents the time a ticket was actively being worked on as a percentage of the total time (i.e. Lead Time).

Flow Efficiency is expressed as a percentage of the overall delivery time. It enables teams to quickly pinpoint stages in the delivery process where excessive friction or “waste” exists. By reducing the process “waste” and time spent in a queueing state, teams can quickly and quite dramatically increase their time to market and throughput without the need to increase headcount.

Key use cases

Delivery Lead Time is often used as a critical ‘North Star’ metric around which to drive the continuous improvement of the software delivery team and to encourage teams, squads and tribes to remain focused on satisfying their internal customer demands by delivering value as quickly and efficiently as possible.

Helpfully Lead Time can be tracked at all levels within the delivery capability – it is very useful at team level to identify and remove delivery bottlenecks – but it is also very useful to track over time at an aggregate level, to track improvement in the overall effectiveness of an organisation’s software delivery capability.

Analysis of Lead Time is therefore a key agile delivery metric for any software delivery team looking to improve delivery efficiency and throughput.

Key uses cases of Lead Time are:

  1. Teams looking to take an end-to-end view of the SDLC, from ideation to deployment, in order to really understand where friction may lie
  2. Teams that are looking to increase speed to market and increase throughput or velocity
  3. Teams looking to identify bottlenecks in the software delivery process, particularly as they grow in size and complexity
  4. Teams looking to mature their Agile DevOps capability and continuously improve their delivery effectiveness around some simple Agile delivery metrics (KPIs).

Expected outcomes

By reducing Lead Time, delivery teams should expect to see the following outcomes:

  1. A reduction in time to market for new functionality (evidenced in Lead Time and Cycle Time)
  2. An improvement in overall throughput (e.g. a Scrum team’s increased velocity)
  3. A reduction in resolution time for bugs
  4. Increased morale in the team (process inefficiencies are detrimental to team morale)
  5. Stronger collaboration amongst team members and increased awareness of the delivery objectives of the team and internal customer needs.

 

share this post